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.

Most of our teams complete 10 or more user stories per sprint. When answering the 3 questions in the daily Scrum, it was clear what each person was working on, but it wasn’t as clear how each story was doing or when a story was in trouble. For example, if no one worked on a story, problems with that story aren’t visible because no one mentions that story during the standup. What we’ve started doing is conducting the daily standup story-by-story rather than person-by-person. Now it’s very clear how each story is progressing, but difficult to figure out what each person is doing. Some people work on multiple stories and others may not even speak up in a daily Scrum.

One possible solution to this common problem is that these teams are doing too many product backlog items per sprint. Based on data I analyzed on successfully finished sprints, I determined that a team should average around 1 to 1-1/2 user stories (product backlog items of any sort, really) per person per sprint. So, a six-person team should get somewhere around 6-9 user stories done per sprint. Teams doing shorter sprints (one or two weeks) should be at the low end of the range; teams doing three- or four-week sprints should be at the upper end. This means that coincidentally teams with longer sprints do slightly larger user stories in their sprints.

I hate that the answer I got was around one user story per person in a sprint because that makes it sound like each person grabs one user story and works on it alone for the duration of the sprint. Nothing could be further from the truth. Expressing the number of items in terms of the number of people on the team is just an obvious way to state the result: more people, more user stories. I want to reiterate though that the result is not for each person to do one user story per sprint alone.

Another solution to the problem above is to conduct the daily standup in front of a physical task board and have people point to whatever they are working on. I always prefer to do this whenever possible. I frequently ask the speaker to “Point to what you’re working on.” Assuming a well setup task board this will show me the user story that the task relates to.

Another solution is to designate a “point person” for each user story the team plans to work on in the sprint. This person is responsible for knowing if the user story is moving along appropriately. The person is essentially a “story owner” but we’re talking about 2-5 minutes a day of extra work. This isn’t a heavyweight new responsibility. The person may or may not be the primary contributor on the story; it doesn’t seem to matter.

Another possible solution could be to look at the sizes of the teams involved. I find the ideal team size is 5-7 people. Standard agile advice seems to be 5-9 is the right size. When possible I try to stay on the low end of the range. If the team is more than 9, it is easy to lose track of what people are doing.

Finally, most teams do the daily standup per-person, but some encounter the problem described here and discuss things story-by-story. Not all teams need to do it the same. If you’re in an organization with even a handful of teams, I would randomly split them and tell some to try person-by-person and others to try story-by-story for a full sprint. I’d get everyone together afterwards for a short cross-team retrospective and let people say how it went. Hopefully teams could hear the results of other teams and then make a good decision about what to do next.

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).