tagged: sprint-backlog

Sprint Backlog Sums All Work Remaining

I want address a couple of common questions surrounding sprint burndown charts:

1) Is the burndown adjusted based on all tasks remaining in a sprint backlog or only those tasks that are in process?
2) During a sprint, if a bug is discovered on a user story being worked on, should we add additional tasks to the sprint backlog and should we adjust the burndown for those tasks?

Why There Should Not Be a “Release Backlog”

I haven't heard the term "release backlog" in many months, but it's come up in three conversations over the past week. So, I want to share my thoughts on whether a team using an Agile project management approach should have a backlog known as a release in addition to the conventional Product and Sprint (or Iteration) Backlogs.

First, let's clarify what people mean when they…

Why I Don’t Use Story Points for Sprint Planning

As described in Agile Estimating and Planning, I'm a huge fan of using story points for estimating the product backlog. However, I also recommend estimating the sprint backlog in hours rather than in points. Why this seeming contradiction? I've previously blogged on the reasons why I recommend using different estimation units (points and hours) for the different backlogs. But…

Sprint and release planning should be in different units

A common source of confusion on agile teams occurs when the sprint ("iteration") backlog and the product backlog are both estimated in hours. To avoid this confusion I strongly recommend estimating these backlogs in different units. In sprint planning the team should always talk of tasks and hours. Sprint planning covers the horizon of typically two to four weeks out. In…

Instant Access

Sign up to get Mike’s blog posts delivered right to your inbox as they publish.