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

Agile Burndown Charts at a Glance

The Agile Burndown Chart Gauges Sprint Progress

For those new to agile, a Burndown Chart is a graphic representation of sprint status. The vertical right axis shows the number of Story points brought into the sprint. Across the bottom, you see the number of days in the sprint. Most charts also display the perfect 45 degree angle Burndown.

The ideal Burndown Chart gives you the impression that it is possible to complete Stories in a smooth process of building application functionality and closing Stories. However, with agile projects, just like with all other projects, progress can be a bit bumpy.

I love Burndown Charts, because all you need to do is glance at a Burndown Chart to easily see how the team is managing the sprint. It is quite a powerful tool. Root cause of what created the peaks and valleys of the Burndown provides excellent food for discussion at Retrospective.

A typical Burndown Chart might look like the one below:

Sample Burndown Chart for a Sprint

Sample Burndown Chart for a Sprint

There are 2 negative indicators you do not want to see on your Burndown Chart:

  1. Flat lines mean that no Stories have closed in one or more days.
  2. Upward peaks mean the team brought in new Stories after the start of the sprint.

How to Combat Flat Lines

A Story can stay open for several reasons: it is larger than sized; it is blocked and the programmers need intervention from the Scrum Master; or the team is not practicing pair programming and every programmer has his or her own Story in progress. You get the idea.

If the team flat lines early in the sprint for more than 2 or 3 days, figure out why Stories aren’t closing, take action and get the sprint on track. If you don’t, the sprint could end up going off a cliff, like what happened in the Burndown Chart above. When the team does not close Stories in timely fashion, it cannot meet its sprint commitment and Stories remain unfinished at the end of the sprint. These Stories are removed to the Backlog at the end of the sprint. The team does not get credit for any work completed and they also risk missing key project milestones.

How to Combat Peaks

Yes, sprints are supposed to be time-boxed. Once started, the team works diligently on the Stories allocated to the sprint and the Product Owner freezes new work orders for the next few weeks.

In real life, stuff happens. The team realizes that it would be more efficient to work on a different aspect of the application first or a major emergency occurs or the team forgot something. There are lots of reasons why the team breaks the sanctity of the sprint and adds new Stories.

In the Burndown Chart above, you can see 5 mini-peaks where Stories were added. This definitely contributed to the cliff at the end.

More often than not, multiple peaks in the Burndown Chart indicate that the team is not doing a good job of deciding what to bring into the sprint. If this happens during multiple sprints in a row, the team should discuss the issue at Retrospective and try new ways to develop more predictive behavior. The team cannot accurately plan for and meet its commitments if it has trouble deciding what to work on next.  

If your sprints are longer than 2 weeks and you continue to see peaks, I recommend shortening your sprint cycle to 2 weeks. The team may also consider amending the team contract to include rules for determining whether or not to allow new Stories to be brought in mid-sprint.

Look at the Burndown Chart Every Day at Standup

To expedite standup and keep it under 10 to 15 minutes, many teams are tempted to skip looking at the Burndown Chart and go directly to the Story Board. Resist the temptation.

Use the Burndown Chart to gauge the team’s progress at a glance and take corrective action early.

If the team is regularly closing Stories, the Burndown Chart will reflect its success.

Celebrate wins too!

Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

Contact Us read more