Creating the Sprint Backlog for Testers Part 2

When it comes to setting the planned velocity for the next Sprint, It’s not advisable to only base it on the previous Sprint’s actual velocity, since a single Sprint will not be as indicative of the work they can manage. There really is no fixed number of Sprints to get the average velocity, a good number of Sprints would be about three to five Sprints.

Since estimating story points earlier on in the project is challenging, it is fair to expect the first few actual Sprint velocities to have big differences from the planned Sprint velocities. Scrum teams who are new can take several Sprints to stabilise their estimates. Just as story point estimates can be improved by ironing out processes in Sprint Retrospectives, setting the planned Sprint velocity can improve over time.

There are several online Agile project management sites or tools that Scrum teams can use to track their velocity and other metrics. Such tools are used for storing the Product Backlog and Sprint Backlogs as well as facilitating Sprint ceremonies and tracking tasks. These tools can also compute metrics such as velocities and can be used to generate reports.

Committing Work within the Sprint

A completed Sprint Backlog is where the user stories are clear to everyone, sized, and committed to be finished. Having a sound estimate for planned velocity should allow the Scrum team to commit the right amount of user stories to work on within the Sprint. It can also be used for negotiating the scope for the Sprint. Some user stories may need to be resized and rescoped, in instances where the current size of the Sprint backlog doesn’t meet the planned velocity.

Once the Sprint backlog is committed by the team, they can track their progress throughout the Sprint in a burn-down chart. This is a graph that shows the ideal trend of the Sprint, starting with the current Sprint backlog size or planned velocity, and then slanting down to 0. Each day of the Sprint, the team will update the chart by telling the Scrum Master what was finished the previous day, and letting the Scrum Master know how many story points to take off from the chart.

Testers should ensure that their tasks are accounted for in estimating story points and velocities when creating the Sprint backlog. Knowing the Scrum team’s capacity is just as important as deciding what user stories should be scoped. Setting and tracking Sprint velocities will be useful for managing the amount of work to be done.

<– Continue Reading –>

Our Book Recommendations

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