Creating the Sprint Backlog for Testers

Sprints can simply be too short for testers – especially when work isn’t planned properly. Thankfully, Scrum is an empirical process, and empiricism requires transparency to inspect and adapt on. This article will be about creating the Sprint Backlog, and how tracking Sprint metrics can help Scrum teams – including testers – to plan work effectively.

Sprint Velocity and Team Capacity

Creating the Sprint Backlog during Sprint Planning is about first selecting the Sprint goal then deciding how to meet it. This means they select the user stories for the Sprint. But equally as important  is ensuring that the Scrum team has the capacity to do so. The best way to scope user stories for a Sprint is to know first how much work the Scrum team could commit on any given Sprint – this is what the Sprint Velocity is about.

Sprint Velocity is the measurement of how much work the Scrum team can take in during a typical Sprint. This is tracked by noting how much work was marked as “Done” after the Sprint Review, comparing it to the estimated velocity for that Sprint, and then plotting it along a Velocity chart, which should also display the actual vs planned velocities. Reading the team’s velocity will depend on which metric they decided to use for estimating work. For example, if the team measures with story points, then they will add up the points of completed stories.

Estimating the Velocity

To estimate the velocity of the Sprint during the planning ceremony, the Scrum team should take the average velocity from different Sprints. For example:

Sprint 5 – 09/17 – Actual Velocity: 21; Planned Velocity: 21

Sprint 6 – 10/01 – Actual Velocity: 25: Planned Velocity: 25

Sprint 7 – 10/15 – Actual Velocity: 20: Planned Velocity: 20

Sprint 8 – 10/29 – Actual Velocity: 23: Planned Velocity: 23

Based on this example, when the Scrum team in question is planning for Sprint 9, then their Planned Velocity would be about (21+25+20+23) /4 = 22 points. It should be noted that velocity is not a key performance indicator, but more a tool for estimation. For example, if the Scrum team planned for 25 story points total, but only finished 10, it could have happened due to unforeseen impediments or an inaccurate estimate. Comparing velocities of different teams can also be a misleading metric, since they will have different Definitions of Done (DoD) and different ways of dividing user stories. One team’s DoD may require automated tests to be part of a user story, while another team is tracking automated test creation as different user stories altogether.

<– Continue Reading –>

Our Book Recommendations

We found these books great for finding out more information on Agile Scrum: