Archive for March, 2008

Prioritizing Tasks Within a Sprint

Friday, March 21st, 2008

In the discussion that ensued from another post here, Brian Bailey asked a great set of questions. The questions were big enough that I’ve moved them here. I’m going to intersperse Brian’s questions and comments with my responses. Brian started with:

If the product owner is onsite and part of the same company, what role should she have in prioritizing tasks within a sprint? To clarify, I assume that a 30-day sprint does not mean that new features that are completed are held until the end of the sprint. If a feature is finished and ready to move to production after the first week, it can be released, correct?

If that’s the case, should a PO be allowed to prioritize the stories and tasks the team committed to (“Please start with this critical item”) or should the team have full control over the order things are worked on?

First, the concept of prioritizing tasks within a sprint is one that doesn’t make sense. When a team plans a sprint they make a commitment to complete the user stories they select from the product backlog. It’s not a come-hell-or-high-water commitment, but the team is expected to do its best to complete the work they select. And averaging things out over the course of many sprints, the team should generally meet their commitment.

The idea of prioritizing items within a commitment doesn’t make sense. Back in 1988 I got married and made a commitment to my wife, Laura. I promised to love, honor, and cherish her. (We mutually agreed to drop “obey.”) I didn’t promise to love her all the time, honor her if there was more time and then cherish her as a stretch goal.

But what about Brian’s statement that, “I assume that a 30-day sprint does not mean that new features that are completed are held until the end of the sprint.” Well, yes and no. This depends upon what was agreed to during sprint planning. The default assumption should be that the team has the right to rip the system apart on day one of the sprint and does not have to have it put back together until the last day. (For argument’s sake, I’m ignoring that this would be a bad idea for many reasons.) If the product owner needs an interim deliverable during the sprint, that should be discussed and planned during the sprint planning meeting. There will almost certainly be some overhead in doing this and the team needs to account for that. Even better, though, I’d suggest trying a shorter sprint length if this is common.

Back to Brian:

And of course, the dangerous follow-up that almost seems inevitable – could the PO then decide or shift priorities (not adding or replacing tasks, though) throughout the sprint?

I’m confident this is a bad idea and could lead to micro-management instead of team-driven development. But I can also see how the PO might have a good reason for something to be moved to the front of the line.

You’re correct. This is a bad idea. One of the challenges with 30-day sprints is that it is a long time to make the business go without changing its collective mind. If this questions are legitimate concerns then a shorter sprint length is a likely solution.

Posted in Sprinting | 6 Comments »

Certified Product Owner – interview with Mike Cohn

Thursday, March 20th, 2008

Mike Cohn was recently interviewed by Artem Marchenko.

Posted in News | No Comments »

When Should We Estimate the Product Backlog

Sunday, March 16th, 2008

I was recently emailed a question asking whether the sprint planning meeting should start with time allocated for putting story point estimates on any user stories that have not yet been estimated.

No, I don’t think this is a good idea. Keep in mind that we put estimates on product backlog items (which I recommend be user stories) so that:

  • the product backlog can be prioritized. It is impossible to fully prioritize a set of items without knowing at least their relative cost.
  • we can make high-level forecasts about how much will be done by when
  • we can make tradeoff decisions between scope and schedule

We can achieve these goals with approximate, relative estimates such as given by story points. For example, if I decide to buy a new car this weekend it is sufficient for me to know that I can get a Toyota or Honda for around $30,000 and that a Ferrari goes for closer to $800,000. I do not need to know a more precise cost of the Honda ($31,850) before knowing it should be on my short list of cars to evaluate while the Ferrari should not.

Sprint planning meetings typically go into deeper detail than is appropriate for product backlog item estimating (whether in story points or ideal days). Since we become accustomed during sprint planning to breaking user stories into tasks and considering those tasks in more detail, there is a chance this will carry over into any story point estimating done during the same meeting.

So, when should story point estimating happen? I’ll describe the ideal case, which you can easily adjust for the real-world intrusions on your project. Projects typically start in either of two ways:

  1. A reasonably fully stocked product backlog is written before the first sprint begins and all items are estimated before the first sprint planning meeting. [If you do this, be careful not to write all user stories with too much detail. Each product backlog item you write represents an investment. User stories should therefore be elaborated just-in-time and in just-enough detail that they can be turned into functionality in one sprint.]
  2. We know we’ve got to do the project so we dive in. During the first sprint or two, all the user stories are written and estimated just like above.

On an ongoing basis, once per sprint I recommend that the ScrumMaster tell the team something like, “Hey, we’ve had five new user stories come in this sprint and we need to estimate them. Everyone plan on hanging around for a bit after tomorrow’s daily scrum meeting and we’ll play Planning Poker to estimate the new items.” Doing it right after the daily scrum helps cut down on the number of interruptions in total. I usually aim for having that meeting about two days before the end of the sprint. That way the product owner will have estimates on them so she can prioritize prior to the start of the sprint.

Posted in Agile Estimating | 21 Comments »