Sprint Zero (2019)

Sprint Zero

What is Sprint Zero

At the beginning of a new piece of work, some teams will choose to run a Sprint that focuses purely on setup first. These can include anything from the Scrum Board through to source code repositories, Wikis to staging, and even production deployment pipelines.

 

This Sprint is often called Sprint Zero, although it is not officially recognized or sanctioned by the Scrum guide. Sprint Zero does deviate from the Agile Manifesto in that it delivers little or no working software at the end of it.

 

It's also not uncommon for teams to try to expand the Sprint Zero well beyond the usual iteration length—5 to 6 weeks isn't uncommon. This is a sign that the transition from a Waterfall-style delivery to an incremental one is too difficult for some to make.

 

As a coach with experience, this feels like procrastination. Sprint Zeroes can be used by teams as an excuse not to transition to an Agile approach, but instead stay comfortable with what they know. In this case, procrastination is a form of applied anxiety.

 

The one thing that I can honestly say is that if we always stick with what we know, we may never discover if the alternative is better. It's important that we experiment and are not afraid to fail.

Scrum is an empirical process, so 'failing' is more of a discovery of what works and what doesn't!

 

Instead of using Sprint Zero, treat the tooling and infrastructure that you need to set up just as you would each feature: deliver it incrementally.

 

You can do this either as part of each feature, by looking for User Story candidates in which you can include infrastructure setup, or by defining small User Stories that can be interwoven into your Product Backlog alongside feature delivery.

 

For instance, the first User Story will likely include setting up the source code repository and creating an initial deployment pipeline to a staging environment. Subsequent User Stories will likely include logging and enhancing the deployment pipeline to point to a production environment, and so on.

 

If you treat your infrastructure setup as you do your feature delivery, you can maintain maximum flexibility by delivering just enough to move forward. To avoid making assumptions, we need to solve the problems we have now, not the problems we don't have yet.

 

A day in the life of a Scrum team

Each day at the specified time, the team meets at the Scrum Board for the Daily Scrum. Once the Daily Scrum is complete, the team may then catch up with each other to discuss certain work items in more detail, or perhaps to demonstrate the work completed so far to the Product Owner to see if it's heading in the right direction.

 

Working as a Scrum team requires a coordinated effort that will often extend beyond the Daily Scrum. It's not often that team members operate in isolation from one another. Co-locating your team means you can pick up from the environment how others are progressing, even if people are working individually on a task.

 

You'll often find Scrum team members completing work before the next Daily Scrum, who will need to find another task on which they can work. If necessary, they can call an impromptu standup around the Scrum Board to discuss things with the team and make sure they are selecting the right thing to work on.

 

It's also important to keep focused on the Sprint Goal, and you should ask yourselves regularly how confident you feel in reaching it. You could do this as often as every day, for example, at the end of every Daily Scrum.

 

One technique we could use for this is called Roman Voting, where you use your thumb to indicate your vote: either up for yes, you're confident, down for no, you're not convinced, or sideways for you're on the fence.

 

If the majority of team members are not feeling confident or are on the fence, then you should encourage talking as a team to determine if there is anything that can be done to improve confidence in completing the Sprint Goal.

 

To help determine what course of action to take, you can use visual techniques to help enhance your understanding—something we'll look at in the followings section.

 

Measuring and reporting progress with visualization

The Scrum Board itself gives a clear picture of how a team is tracking. It's immediately apparent which User Stories are in progress, and on which tasks the team is busy working.

 

It's possible for us to enhance the information that the Scrum Board radiates in ways that will make the status of the Sprint more evident, and therefore the conversation at the Daily Scrum less about the team's status and more about the work and coordinating around it.

 

The following subtle visual additions should allow you to reduce cognitive overload, enabling the team to focus more on the work at hand and less on managing the process around it. Of course, these are just suggestions; if you can think of any others, then by all means experiment.

 

Avatars

Create avatar cards to represent each team member. A picture stuck on a card backed with wall tack will work; laminating them will increase their longevity. You can then place these on a board to represent which task team members are working on, as in the following figure:

 

This shows that one team member is working on the third task of the first User Story. Two other team members are working the second task of the second User Story. Using avatars reduces the time taken at the Daily Scrum, as when each person talks, it's clear what they are working on.

 

It also helps to coordinate work outside of the Daily Scrum. For example, when looking for their next task, if a team member can easily see who is working on a User Story, they can coordinate with those team members.

 

Done stickers

Done stickers are simply post-it notes with the word DONE written on them. We place them on a User Story to show that it's done—meaning that all work is complete, including those items on the DoD. The following figure shows a 'DONE' sticker on the first User Story:

 

Burndowns

At the end of Sprint Planning, after the team has broken down User Stories into tasks, the Scrum Master totals up the number of tasks in the Sprint Backlog. The Scrum Master then creates a Burndown chart.

 

The following diagram shows a Burndown for a Sprint already in progress:

  1. The y-axis represents the total number of tasks. The x-axis represents the number of days in the Sprint.
  2. The red line on the following Sprint Burndown chart represents the number of tasks left to complete.
  3. The dotted line represents the Ideal Burndown rate in order to complete all tasks by the end of the Sprint; 

 

In this case, the Actual Burndown shows that new tasks were discovered when the team began working on a User Story, and so the total number of tasks has increased. It is not unusual to uncover new information once work commences.

 

Sprint Goal confidence

In the previous section, we looked at how to run the first Daily Scrum event. We discussed that a Daily Scrum was a good place for a team to review if they felt they could still meet the Sprint Goal by the end of the Sprint. We used Roman Voting to express our level of confidence.

 

we've used them to record each team member's vote so that we can see from Scrum-to-Scrum how things are changing.

 

We can use this to decide if we need to do anything to improve the process. For example, if there is a sudden drop in confidence, perhaps it's worth re-planning the approach to completing the Sprint Goal:

 

The importance of visible workspaces

Making work visible in the form of a Scrum Board is one of the most empowering features of Scrum. We often call visible workspaces information radiators because they radiate information to anyone within sight of them.

 

Scrum Boards enable several things to happen:

1. A visible workspace allows a team to debug its process like never before. A team can stand back and take in a complete picture of a Sprint's progress. If you're new to Agile, this gives you information that you've never had before.

 

The visible nature of the work in progress enables you to make better decisions. It's not uncommon to see Scrum teams gathered around the board outside of the Daily Scrum, assessing the state of play and deciding what to do.

 

2. Stakeholders can also easily assess the work in progress by visiting the Scrum Board. This results in fewer interruptions to the Scrum team.

 

3. Transparency leads to easier risk management. At a glance, you can determine if an item in progress is blocked and needs assistance, and from the wider perspective, if you're likely to meet the Sprint Goal.

 

In a non-Agile environment, this information is usually kept online in a project planning tool or spreadsheet, making it less visible.

 

Online tools can be useful, especially when used for tracking trends over time or when people work remotely. However, we often call online tools, such as Jira, PivotalTracker, Rally, or Trello (to name a few), information refrigerators because although they store information well, it's hard to see.

 

You have to go to the fridge, open the door, and poke around. Often, the thing you're looking for is down the back, covered in ice and hard to spot.

 

The tools that enable you to do this easily are your visible workspaces; in other words, your Scrum Board and your work which is made visible on it.

 

Using the Scrum Board, you can easily track the progress of your User Stories and their related tasks. The completion of a task also feeds into your Sprint Burndown, giving you an idea of how close you are to completion.

 

Removing impediments

Part of the Scrum Master's role is to remove any impediments that are in the way of the team carrying out their work. It's sometimes hard for team members, particularly those new to Scrum, to recognize what is and what isn't an impediment.

 

For example, if you're waiting for your operations team to set up a staging environment for us to perform user acceptance testing and everything else has been done to this point, then this is impeding the completion of this work.

 

However, the team might not view this as a problem because it's just the way things have always been done. The Scrum Master has to start to develop a nose for this stuff in order to smell real impediments.

 

We use the term smells as a metaphor because, just as in real life, the cause of the smell isn't always what we think it is. Using the term 'smell' allows us to sniff out a potential problem without jumping to conclusions or laying blame.

 

If our nose turns out to be correct, we can help our team avoid any nasty bumps in the road. If we're wrong, then it's better safe than sorry.

 

Bad smells for a Scrum Master include, but aren't limited to:

  1. A team member talking about something they're working on that isn't visible on the Scrum Board
  2. A team member not speaking at the Daily Scrum
  3. A small task that should have only taken hours hasn't made any progress in a day or longer

 

The Sprint Burndown is tracking to target—normally, a Sprint Burndown tracks up before it tracks down; new tasks are often added when work on a User Story commences, so if the Sprint Burndown is tracking exactly to the expected burndown rate, something fishy is happening.

 

Managing delivery as a team sport

When transitioning to Scrum, you may notice that you'll be better able to manage your workload. When you think about it, this makes much more sense; the people who are actually doing the work are the people best placed to understand its progress and value.

 

When a team forecasts User Stories to be completed during Sprint Planning to create the Sprint Backlog, they're setting up an informal commitment with a Product Owner. Here, we're saying that we will complete this work on the provision that:

  1. The Sprint Backlog remains fixed; there are no sudden changes such as altering priorities or swapping out stories.
  2. We're given the time, freedom, and space to work.

 

If we're able to reduce interruptions coming into our Development Team as much as possible, it allows us to focus on what we need to do. Instead of asking a Development Team member to do something "urgently", an urgent task can be placed at the top of the Product Backlog, where it will be picked up in the next Sprint.

 

Giving a team this latitude within the Sprint boundary means that they will become better at self-management. In fact, they're much more likely to complete the work and achieve the Sprint Goal if they're allowed to determine how to best organize themselves.

 

Another factor to consider in the successful self-organization of a team is subtle control. For a Scrum team, decisions on what to build ultimately stop with the Product Owner, and these decisions are influenced rather than directed by the wider stakeholder group.

 

The last day of the Sprint

We will now conclude the Sprint with two events: the Sprint Review, followed by a Sprint Retrospective. Both of these events give us the opportunity to inspect and adapt the work we've carried out during the Sprint.

 

We always hold the review first because the conversation there is likely to spark further discussions and raise action points at the retrospective.

 

Event – Sprint Review

The Sprint Review's focus is on the increment of working software that has just been built and how successful the Sprint has been in moving the product's progress forward.

 

This is how you set it up:

What you'll need: A large screen to demonstrate your working software, the User Stories you've completed, the User Stories you didn't complete, the Sprint Goal, index cards, sharpies, and post-it notes

Setup: A large table that the whole team can fit comfortably around with a view of the screen

Attendees: The Scrum team and stakeholders Time-box: 4 hours for 1-month Sprints; for shorter Sprints, the event is usually shorter

 

The central focus of the Sprint Review is for your team to demonstrate the working software they've built as part of the Sprint.

 

They should decide upfront which member of the Development Team is going to show the working software. You may decide that it will be a group effort, in which case, you should decide which team members will show which of the completed User Stories.

 

The basic flow for the Sprint Review should be along the following lines:

  1. The team member who is demonstrating the first complete story reads out the story card, including the acceptance criteria.
  2. They then demonstrate the software and explain how it meets the acceptance criteria.
  3. They then ask for any questions or observations.
  4. The team member who is demonstrating the next complete User Story takes that story card and repeats the process.

 

The Sprint Review is an opportunity for you to engage your stakeholder group and gather feedback on whether the product is moving in the right direction. Of course, your Scrum Master and Product Owner should be able to recognize that this is the first Sprint and that the software you've delivered won't necessarily show a complete set of features.

 

Once all complete stories are demonstrated, the Sprint Goal should be read out by the Product Owner, and the team should discuss and review whether they've achieved all, part, or any of it.

 

The final part of the Sprint Review is to open the room to any questions or observations. For example, the invited stakeholders may be interested to hear what the team has planned next.

 

They may also be keen to offer feedback about the direction the team is moving in, or even suggest changes or a new direction. This feedback is likely to be incorporated into existing User Stories or may even create new User Stories.

 

The worst case scenario during a Sprint Review is that there is no working software to demonstrate, which can happen if a team hasn't completed any User Stories or if the working software is hit with technical difficulties. If this happens, the team should move directly to the Sprint Retrospective.

 

Take time to prepare for the Sprint Review. It is a demonstration of working software, so the last thing you want is a case of non-working software. Make sure that you've got a working demo before you start.

 

Unfortunately, I've seen Sprint Reviews canceled on a couple of occasions because the team failed to get their software working. In these instances, there was a room full of stakeholders who left dissatisfied.

 

Sprint Retrospective

The Sprint Retrospective is an opportunity for the team to reflect on their first Sprint. You should look at what went well, what didn't go so well, and what can be improved.

 

Your Scrum Master facilitates the Sprint Retrospective. There is a degree of preparation required to run a retrospective, and so we recommend heeding the following format:

 

Setting the stage: The Scrum Master presents some facts and figures from the last Sprint. They should aim to paint a picture of what happened. Did the team meet its Sprint Goal? What was the team's velocity? How did the Sprint Burndown look?

 

Gather data: At this stage, the team needs to collect more data about the Sprint. On the whiteboard, the Scrum Master draws quadrants for the four following categories:

  1. What went well?
  2. What didn't go well?
  3. Ideas for change
  4. Shout Outs

 

Using post-it notes and a sharpie, write as many post-its as you can think of (one item per post-it) that fit into either one of those four categories. The Scrum Master will keep the time-box, and the team should work silently. They can then place the post-it notes on the board as they go or wait until the time-box is up.

 

Once done, you should end up with something like the following:

1. Generating insights: At this point, you should examine what everyone has written as a group. You can see, for example, that three people have mentioned automated testing in the 'Ideas' quadrant. You can also see that the team agrees that there are too many distractions.

 

2. Decide what to do: Next, you need to decide how to improve the next Sprint for the better. For this, you can either take an item from 'What went well' and decide how to amplify it.

 

The Scrum Master will ask the team to vote on what needs to be done. Team members get three votes each and each vote must be written on one post-it note.

 

In the following instance, we use gold stars to vote:

So, now it's time to create actions for each of these. Aim to take two to three actions from each retrospective, and no more. You're aiming for small incremental changes that can be introduced with each Sprint. Your goal should be to make your actions SMART: Smart, Measurable, Agreed upon, Realistic, and Time-based.

 

Here are some suggested actions that fit the SMART approach:

  1. ACTION: Less discussion at the Daily Scrum
  2. WHAT: Set up an 'After Party Zone' on the Scrum Board. Any topics for discussion should be recorded there so that the team can talk about them in the After Party.
  3. WHO: The Scrum Master will set up the After Party Zone area on the board and record any relevant topics.
  4. WHEN: At subsequent Daily Scrums.
  5. ACTION: Automated testing.
  6. WHAT: Implement a test framework when working on the next story to facilitate learning.
  7. WHO: Jono and Rupesh.
  8. WHEN: The next Sprint.

 

3. Close: With the retrospective actions complete, the Scrum Master closes the retrospective. They ask each team member to give one sentence to describe their experience of the retrospective.

 

The Scrum Master will then place the retrospective action items on the team's Scrum Board to be worked on during the next Sprint.

 

Summary

In this blog, we guided your team through their first Sprint. There were a lot of activities needed to get us this far, and to give us the right foundation for moving forward.

 

Remember that it will probably take four to six Sprints for a team to hit its rhythm. No matter how successful you are in delivering something at the end of that first Sprint, the important part is that you did it! You and your team have now successfully transitioned and can use an iterative, incremental delivery style.

Recommend