Hacking the Set Up of Your Scrum Team to Start Delivering Within 48 hours

I’ve seen the process of getting scrum teams to take anything from a week to a month, depending on how long the project is due to run and the bureaucracy involved. 

But it doesn’t need to be like this! The point of Scrum is to deliver value fast, and incrementally, to end-users. Having a lengthy setup process sets the wrong precedent for the team. You can hack the scrum process and get the team up and running in 48 hours if you focus on what matters and are prepared to deal with uncertainty. Here is your guide to getting set up.

The most important thing for the team is to first define why it exists. The objective is to understand the business problem the company is trying to solve. Why was this team created? What are the measures of success of whether this team has done a good job? Ensure that the whole team is involved in this activity to build a shared understanding. 

Output: A statement that summarises why the team exists, with associated metrics to measure success.

Working as a team means having a shared understanding of what everyone is doing. Your project management software is key to this, with JIRA being by far the most popular tool on the market. However, tools like Trello, Azure boards, and Github issues can all be equally effective. Ensure that everyone has access, a project has been set up, and there is a Kanban board with statuses that everyone understands. Also, take the time to do some basic training so that everyone can navigate the project and understand how this is set up.

Output: A shared project for tracking and managing the backlog, with agreed Kanban board columns with a collective understanding. Everyone has access to the project.

Now it's time to write down all the work the team thinks it needs to do. In the beginning, do not worry about the detail of the tickets. Write down everything that people think needs to be done, or alternatively, what everyone is working on if the team has already been formed. The key principle here is transparency amongst everyone over the current state of play. Resist the urge to detail these tickets - that will come later! Only some will be worked on immediately, so don't waste time getting into the weeds. Aim to describe the problem at a high level, create a placeholder ticket with a couple of lines of description, and move on.

Output: A list in your project tracking tool with all the work required to be done.

Session 4: Backlog Refinement

Now you have collectively splurged all the backlog items, have an initial discussion about which ones should come first - either in terms of business priority or logical order of completion. Revisit those that are most important, drag them to the top of the backlog, and begin detailing them. Focus on capturing acceptance criteria, and describing what info is still needed to be able to begin work on the task. Ensure you capture questions rather than trying to answer them in the session. Again, be comfortable with the uncertainty! There are likely to be lots of unknowns at this point.

Output: A backlog with some initial ordering and the top handful of tickets with acceptance criteria and further information.

After a good night’s sleep and a strong cup of coffee, the goal of the first workshop of Day 2 is - how do we move code to Production? This may be very self-evident to the team, but often there are gaps in understanding around the process and approvals needed. Make this explicit early to speed up the team later. If there are actions that need to be taken to set up the Continuous Integration or Deployment, add it to the backlog.

Output: A process flow diagram of how code moves from local to Production, annotated with current gaps.

It's time to start your first sprint. Setting the right sprint planning behaviors is critical. Start with a sprint goal - what do we want to achieve by the end of the first sprint that delivers business value? Once this is agreed, review the backlog items in the context of the goal, and select accordingly. Your prioritisation yesterday should help with the first collection of tasks. Guesstimate with the team how much you can get done in the first sprint, and then agree with the team an initial plan on who will work on what. 

Output: A sprint goal, a sprint backlog, and alignment on what everyone will initially work on.

You may be thinking that now sprint planning is out of the way, you are ready to get going with completing the work. But not quite! The sprint will quickly unravel unless there is a common definition of Done. The definition of Done defines collectively what we mean when a ticket is moved to Done and the criteria that need to be complete for every ticket. Rather than the contents of the definition of Done, it is more important to start building the muscle of checking the quality of all tickets before they are moved to Done, and having a shared understanding.

Output: A list of criteria that each ticket must meet to be marked as Done.

After these intense 2 days, the team should be ready to go with a vision, a sprint goal, a backlog of work to complete, whilst understanding how to deploy to Production and have a common definition of Done. Now the rest of the sprint can progress, holding daily stand-ups to assess progress. 

One of the key strengths of scrum is the continual inspection and adaptation of the process. This is critical to remember during this speed run scrum set up - get enough process to get started effectively, then let the team improve over time. Iteration beats trying to set up the perfect process, to begin with.

Enjoyed this? Follow me on LinkedIn.