Reducing Sprint Velocity may be better for your Scrum Team

Does your Scrum Team need to Buffer Sprint Velocity?

Consistent Sprint Velocity is key to predictable delivery in the real world. If your team’s Sprint Velocity is erratic, it’s hard to determine what to bring into the Sprint Backlog and to meet your Sprint commitments.

Not all scrum teams have the luxury of only working on new development. If your team supports production applications, emergencies may occur that divert the team’s energy. If this happens on a regular basis, it no doubt wreaks havoc on your Burndown. By introducing the concept of a Sprint Buffer, which consciously reduces the number of Story Points brought into the Sprint, the team acknowledges the reality of production emergencies and this helps level out Sprint Velocity.

How does a Sprint Buffer Work?

First, analyze your team’s performance over the last 6 Sprints.
On average, by how much does the team miss its Sprint commitment?

For example, let’s say your team believes they have the capacity to complete 32 Story Points each Sprint.  If your team regularly commits to 32 Story Points, but consistently closes only 26 Story Points and the 6 point miss is because the team is sidetracked by production emergencies, you can face reality and attempt to stabilize Sprint Velocity by giving the team a 20% Sprint Buffer. Reduce the next Sprint Backlog to 26 Story Points. If few or no production issues occur, you can always bring in additional Stories.

Second, track the Sprint Buffer as part of your Sprint statistics.

Every time a team member gets assigned a production issue or emergency to work on, add a Buffer Story to the Sprint Backlog. Do not assign the Buffer Story any Story Points or assign it zero points, because it does not contribute to your Sprint. At the end of the Sprint, record the number of unplanned Buffer Stories completed by the team along with Sprint Velocity as part of your statistics.

Combine Bugs with Project Work in the Backlog

Review every Buffer Story the team is asked to work before adding it into the Sprint Backlog. Is the issue truly an emergency? If the issue is not System Down or there is a workaround to the problem, put the issue into the Backlog as a Bug.

At Story Grooming, size the Bug along with the Stories written by the Product Owner. With a combined Backlog, both new Stories and Bugs can be planned for and brought into Sprints. This technique also helps reduce the Sprint Buffer, while increasing predictability.

Why should planned Bugs get Story Points? This forces the team to think about the level of effort required to fix them. Depending on your Sprint goals, your Product Owner now has the luxury of weighing the amount of development work that must be completed in the upcoming Sprint against the business need to fix high-priority Bugs.

Review the Sprint Buffer Every 3-4 Sprints

The number of production issues worked on each Sprint can vary widely and be unpredictable. Plus, now your team is working on both Bugs and development Stories pulled from a combined Backlog. Every 3-4 Retrospectives, review the number of Buffer Stories that truly require immediate resolution and adjust the Sprint Buffer if needed.

Acknowledge Sprint Buffer Risk to Release Dates

I realize that reducing the team’s capacity appears to dramatically increase the risk that your team will not meet its release dates. But, you already had the same risk, when you missed your Sprint commitments on a regular basis.

Now, however, if your team is on a tight schedule, you raise the realized risk to management and the Sprint Statistics explain the cause. Enlist management to help your team decide criteria for Emergency (work now) vs. Backlog (work when have time).

I’d love to learn how your team manages production issues with project work. Do tell.

 

 

Cynthia Kahn

Cynthia Kahn

 

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

Techniques to Increase Sprint Velocity

Try Applying these 3 Techniques to Increase Sprint Velocity

In agile scrum, we only count closed stories when we calculate velocity. Stories have only 2 statuses at the end of the sprint: 0% or 100% complete. No partial credit for incomplete stories.

Many teams refuse to accept this fact. Scrum does not give partial credit for the simple reason that incomplete stories cannot be delivered to the customer, so they have no value. Because priorities can change at the speed of business, incomplete stories may not rank high enough to be prioritized for the next sprint. If that code was checked in, the code changes for those partially finished stories have to be backed out, which causes even more work that adds no value.

We have found the following 3 techniques help the team close more stories, which improves burndown and results in increased velocity:

  1. Write smaller stories
  2. Ask when story will close
  3. Adopt shared test mindset

Write Smaller Stories

Do your developers pick up stories at the beginning of the sprint and work on the same set of stories for the entire sprint? Does your burndown chart look more like a plateau with a cliff at the end? If this frequently happens with your scrum team, then your stories are probably too large.

Look at your backlog. How many 1 and 2 point stories has your team written? None? Are they all 3 or 5 or even 8 points? If you answered yes, then streamline your approach to story writing.

Remember that a story performs a single function. Take a serious look the slice of functionality defined in your larger story requirements. If your stories describe requirements for multiple, yet related functions, then divide and conquer.

Ask When Story Will Close

At daily standup, the development team answers the following questions:

  • What did I do yesterday?
  • What will I do today to meet the sprint goal?
  • Do I have any impediments?

To keep the eye on the prize and focus on closing the story, we suggest you ask an additional question every day when you discuss the status of every story:

  • When do I think this story will close?

The answer to this question provides insight into the true status of the story. If you don’t like the answer, immediately follow up with: Why? The answer to these two questions help identify the proper next steps, which could include clarify requirements, get help from tech lead or pair the developer with another programmer.

One of the pillars of scrum is transparency. Be honest with each other. Ensure stories that languish get the attention that they need to close.

Adopt Shared Test Mindset

To produce quality products, we recommend scrum teams take a 3-pronged approach to testing:

  • Test driven development
  • Write QA tests when the Story is picked up
  • It’s everyone’s responsibility to test  

If your development team does not have automated testing goals, add them to your team’s contract. Every time you add new functionality to a program, apply the iterative concept of Test Driven Development (TDD): write a failing automated test first, then write the code so the test passes.  

We recommend getting testers immediately involved when the story is picked up for development. Early involvement by testers, who write test cases based on the acceptance criteria, avoids having those resources sitting around for half the sprint waiting to test. It also ensures the team is ready to test immediately after the story is code complete.    

Agile scrum holds the entire team responsible for completing the story. That means testing is everyone’s responsibility. If stories get backed up waiting for testers to test, other members of the team must pick up the slack to get all stuff done on time.

If your team successfully applies these techniques or other techniques that result in a smooth burndown and increased velocity, we’d love to hear them.
Do share.

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more