Posts Tagged ‘sprint planning’

Mix the Sizes of the Product Backlog Items You Commit To

Wednesday, December 30th, 2009

Teams used to a sequential development process have become accustomed to hand-offs between specialists. Analysts hand their work to designers who hand it to programmers who pass it on to testers. Each of these hand-offs includes some overhead in the form of meetings, documents to read and perhaps sign, and so on. In part because of this overhead, the hand-offs tend to be of large amounts of functionality. In the purest meaning of a waterfall process, the entire application is handed from group to group.

Teams that are new to Scrum often do not go far enough in eliminating these hand-offs. They often make the assumption that the programmers should finish programming a product backlog item before handing it off to the testers. This results in lengthy delays at the start of a sprint, when the testers are waiting for a first product backlog item to be handed to them. On a Scrum project, the unit of transfer between disciplines should be smaller than an individual product backlog item. That is, although there will always be some hand-offs (not everyone can be working on everything all the time), the amount of work being transferred from one person to the next should generally be as small as possible.

To facilitate these small transfers, Scrum teams learn to work by doing a little of everything all the time. Rather than an analysis phase (done without the programmer and tester) followed by a programming phase followed by a testing phase, a little of each of those activities is happening at all times.

Even with an emphasis on minimal hand-offs, there will be some product backlog items that will require a week or more of programming time before the programmer can give something even beginning to be testable to a tester. That’s OK. Not everything can be split as small as we might like. To avoid a flurry of testing activity toward the end-of-sprint, avoid bringing a bunch of these complex items into the same sprint. Instead of planning a sprint with, for example, three very large items that cannot be partially implemented, bring one or two large items into the sprint along with two or three smaller items. Some of the programmers can work on the large items, handing them over to testers whenever possible. The remaining programmers can work on the smaller items, ensuring a somewhat smoother flow of work to testers early in the sprint.

While your goal in each sprint should be to do a little bit of everything all the time, some backlog items are complex by nature and will not be completed until near or on the last day of a sprint. To avoid having multiple product backlog items wrapping up the last few days of the sprint, mix the size of the product backlog items you choose to bring into each sprint.

Posted in Agile Planning | 11 Comments »

Two Chapters from Agile Estimating & Planning Avialable

Monday, September 21st, 2009

My publisher, Addison-Wesley, has just made two chapters from Agile Estimating & Planning available for free. Check out Chapter 1, The Purpose of Planning, and Chapter 3, An Agile Approach.

Posted in News | 22 Comments »

Clarifying the Purpose of Iteration Planning

Tuesday, November 25th, 2008

I was recently asked whether it would be OK for a team to complete their iteration planning without going to the point of estimating tasks in hours. To answer this, let’s consider what the purpose of iteration planning is.

In my view, the purpose of the iteration planning is for the team to arrive at a commitment to some set of functionality that they feel reasonably confident they can complete in the coming iteration. The purpose is not to identify tasks. The purpose is not to estimate the number of hours for each of those tasks. The purpose is to figure out how many and which product backlog items they can commit to delivering in the coming iteration.

If a team can do this without discussing tasks and hours, so be it. If a team can walk into the iteration planning meeting and one team member announces, “Sssh, I’ve receiving divine inspiration……… We can do the first three items plus the sixth on the product backlog,” I would call the meeting over and we’d have our commitment. I’d be impressed and I’d be skeptical, but we’d be done with the meeting.

Since I haven’t seen a team do this yet, I strongly recommend that an iteration planning meeting involve identifying tasks, estimating the effort of each, and then using that information to arrive at a set of product backlog items the team can commit to. I think this is the best way for a team to arrive at that reasonable commitment that I believe is the purpose of this meeting. Is it the only way? No. I’ve also worked with teams who decide that they will split work up such that all tasks are “about half a day”. They then can skip explicitly estimating the hours for each task because, in a way they’ve already done it.

But, until I learn how to receive divine inspiration at the start of my iteration planning meetings, I’m sticking with identifying tasks as hours as a good way to figure out how much to commit to.

Posted in Agile Planning, Sprint Meetings | 25 Comments »

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 »

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 »

Why I Don’t Use Story Points for Sprint Planning

Thursday, November 8th, 2007

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 I’m often asked this related question I want to address here:

I’m curious why you aren’t using story points to do your sprint planning.  I thought that the point of measuring story point velocity was partly to determine how much we can take on (or commit to) in a sprint.  Do you only use story points for longer-term planning (e.g. release planning)?

I don’t use story points for sprint planning because story points are a useful long-term measure. They are not useful in the short-term. It would be appropriate for a team to say “We have an average velocity of 20 story points and we have 6 sprints left; therefore we will finish about 120 points in those six sprints.” It would be inappropriate for a team to say, “We have an average velocity of 20 story points so we will finish in the next sprint.” It doesn’t work that way.

Suppose a basketball team is in the middle of their season. They’ve scored an average of 98 points per game through the 41 games thus far. It would be appropriate for them to say “We will probably average 98 points per game the rest of the season.” But they should not say before any one game, “Our average is 98 therefore we will score 98 tonight.”

This is why I say velocity is a useful long-term predictor but is not a useful short-term predictor.

Velocity will bounce around from sprint to sprint. That’s why I want teams to plan their sprints by looking at the product backlog, selecting the one most important thing they could do, breaking that product backlog item / user story into tasks and estimating the tasks, asking themselves if they can commit to delivering the product backlog item, and then repeating until they are full. No discussion of story points. No discussion of velocity. It’s just about commitment and we decide how much we can commit to by breaking product backlog items into tasks and estimating each. This is called commitment-driven sprint planning.

When a team finishes planning a sprint in this way it is indeed likely that the number of story points they have unknowingly committed to should be close to their long-term average but it will vary some. It will also be true that a team will commit to approximately the same number of hours from one sprint to the next. I use the term capacity to refer to this number of hours because velocity is reserved for referring to measuring the amount of work planned or completed as given in the units used to estimate the product backlog (which I recommend be done using story points).

Posted in Agile Estimating, Sprint Meetings | 38 Comments »

The Critical Path on Agile Projects

Tuesday, February 27th, 2007

On traditional, sequential process an important part of the project manager’s job is identifying the project’s critical path. The critical path is the sequence of activities that will take the longest to complete and that, therefore, determines the overall length of the project. For example, suppose that my wife and I want to see a movie this afternoon. Before we can go to the movie she has three errands to run that combined will take her 90 minutes. I only have two errands but mine will take 120 minutes. In considering start times for our film, we better plan on one starting at least 120 minutes from now because my tasks will take that long. My sequence of errands are the critical path for our project of getting to the theater in time for the film.

A common question is “where is the critical path” on agile projects?

Because agile projects are split into a sequence of iterations this question must be answered two ways:

  1. What is the critical path within an iteration?
  2. What is the critical path within a project?

When I first started doing Scrum projects I worried quite a bit about the critical path. I had learned that this was part of my job as a manager. When I would look with my team at a set of tasks we had committed to for an iteration I had a tremendous fear that only I–the all-knowing project manager–would see the critical path. That without me to point it out to the team we would have one day left in each iteration, have perhaps 42 working hours available spread across our 7-person team, have only 38 hours of work remaining. But those 38 hours would all need to be done sequentially. I foolishly lived with the irrational fear that the team wouldn’t see this.

I’ll admit to not getting over this fear as quickly as I look back and think I should have. It probably took me two years of always worrying that this would be the time that the critical path would sneak up on the team and they wouldn’t see it. But after those two years I eventually came to the not-very-insightful but extremely eye-opening realization that the team would always be smarter than me. During those two years (and in the ensuing nine) I have yet to work on an iteration where we neared the end and realized that we mathematically had the capacity to do the remaining work yet couldn’t because of sequential dependencies inherent in the remaining work.

My conclusion from this is that the critical path within an iteration:

  • is easy to see because the iterations are so short (typically two to four weeks)
  • does need to be considered by the team but this can be very informal and usually without even using words like “critical path.” It happens naturally during a team’s iteration planning meetings and daily standups when they ask themselves questions about how they’re going to finish the planned work

Because of these points, my view is not to worry about the critical path within an iteration. Team members will naturally figure it out in the iterations where it’s important.

As for the critical path of an entire project, this is sometimes worth considering. In my Agile Estimating and Planning book, I wrote about rolling lookahead planning, which is one way for a team to deal with elements of critical path planning. Rolling lookahead planning involves teams (on projects with multiple teams) conclude their iteration planning meetings by taking a five minute look ahead at the next 1-3 iterations. This high-level forecast of which features will be added next can help identify dependencies between teams. This is often enough to avoid being surprised by a long critical path.

On a very complex project I wouldn’t be opposed to even drawing a network diagram to see the relationships among the next 3-6 months worth of features (ideally written as user stories). However, before I spent time doing that I would really try first to write mostly independent product backlog items. If a project’s product backlog items are independent and can be developed in any sequence then critical path issues disappear.

Posted in Agile Planning | 9 Comments »

Sprint and release planning should be in different units

Sunday, January 14th, 2007

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 release planning the team can choose between “ideal days” and “story points.” Regardless of which they choose, they still do sprint planning in hours.

I prefer story points for the product backlog items (typically “user stories” are on the product backlog for me). What this means is that I may have a user story (“As a vacation planner, I can see photos of hotels so that I can choose the right hotel for my vacation.”) that is estimate in points–let’s say 5 points. That hangs out on the product backlog (PB) until the product owner prioritizes it such that the team chooses to work on it in a sprint. Once selected it is broken down into tasks and hours:

  • code the user interface, 6 hours
  • code new stored procedure, 4 hours
  • add photo maintenance page, 8 hours
  • write automated tests, 5 hours

and so on.

So both are used but at different times and when viewing items at different horizons.

Here’s a key reason I prefer points:

If I estimate the PB items in ideal days then it is too easy to mistakenly think that the PBIs and the items on the sprint backlog are estimated in the same unit. After all, the sprint backlog is estimated in ideal hours and the PB is estimated in ideal days. So, they’re the same unit (times 8 for the PB), right? This is a huge fallacy. On average the teams I’ve coached spend 30 minutes breaking a product backlog item into tasks and estimating those tasks. So, let’s not call that estimate “hours”. Let’s call it “hours I thought a lot about.” On the other hand, teams I coach spend 2-3 minutes on average estimating the PBIs. (These items don’t need the detailed thought upfront; we just want a rough estimate so we can decide priorities and basic schedule.) So, let’s call these “hours I pulled out of the air.” When the PB and the SB are estimated in days and hours, it is too tempting to divide the number of days on the PB (times eight) by the number of hours finished per sprint and think that’s an estimate of how long the rest of the project will take. However, that’s bad math. It’s literally dividing apples by oranges. It’s “hours I pulled out of the air” divided by “hours I thought a lot about.” The result will be meaningless. The problem goes away when teams go to two-level planning (release and sprint) and when they track velocity in story points.

Posted in Agile Planning | 10 Comments »