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