Posts Tagged ‘sprints’

Should a Team Swarm on to One Backlog Item at a Time?

Monday, October 20th, 2008

This week I want to address the question of whether a team should work on one product backlog item at a time or whether it’s OK to work on multiple items.

In general, a team should feel comfortable working on multiple product backlog items at the same time during an iteration. A typical seven person team will plan between five and ten items into an iteration. They’ll usually be closer to the low end of that range with a one- or two-week iteration and closer to the high end with a four-week iteration. Perhaps surprisingly, though, iteration length has less influence on the number of product backlog items selected than you might think. It seems that teams with longer sprints simply have larger product backlog items.

A seven-person team will rarely be at its most efficient when all team members swarm onto a single product backlog item. There’s too much opportunity for them to get in each other’s way for this to be a good long-term strategy. However, an entire team swarming onto a single product backlog item can be a very effective learning technique and one that I often encourage. If you are part of a team that hasn’t yet learned how all disciplines can work well together, limiting the entire team to one product backlog item in progress at a time is something you might want to try. This forces people to quickly learn ways to work in small batches so that work can, for example, be transferred from programming to testing in multiple tiny increments.

Similarly, if you are on a team where each developer grabs a product backlog item and works independently on it throughout an iteration, a rule of “only one item in progress at a time” is a good way to experience the benefits of working in smaller batches.

So, while I think swarming in this way is an excellent technique to use sometimes, I don’t think it should be the default way of working for very many teams. Some may benefit from it over the long term, but most will find that it introduces too many opportunities to be in someone else’s way as they try to make progress. I consider it equivalent to a drill that a team may do to improve a skill–good to use for practice but not the way to do something forever.

Posted in Sprinting | 15 Comments »

Should the Daily Standup Be Person-by-Person or Story-by-Story?

Sunday, September 28th, 2008

I want to address a question that I got recently and that comes up every month or two. I was recently emailed the following:

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.

Posted in Sprint Meetings | 27 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 »

Correct Use of a Release Sprint

Wednesday, June 27th, 2007

In Scrum we tell teams that at the each of each sprint they need to product a “potentially shippable product increment.” However, “potentially shippable” and “shippable” are not the same thing. Some large or complex projects will require the use of “release sprint” or “hardening sprint” at the end of a release cycle (say 6 two-week sprints then a 2-week release sprint). The release sprint is not a dumping ground for sloppy work; rather it is a place where some hardening of the system can occur.

A great example is a bank I work with. They have 12,000,000 lines of COBOL code that manages bank balances. They have a 1,000,000 line web application that can write to the same database as the big COBOL application. Manual testing of the COBOL system takes three weeks. The web team targets having a potentially shippable application each sprint. They end each sprint pretty sure that they haven’t messed up the COBOL system because they are conscientious developers. However, they don’t know that they haven’t messed up the COBOL system. And they do know that eventually the odds will catch up with them and given enough sprints they will eventually mess up the COBOL system somehow. So they run a release sprint every few sprints before the website goes live. They do the manual system testing that would be prohibitively expensive to do in each sprint at that time. Of course we’d all love the COBOL system testing to be an automated single-button click that could be done in each sprint but since that’s unrealistic in their situation right now it’s done during the release sprint.

If you use a release sprint be sure that the length of the release sprint is independent of the number of sprints that precede it. To continue with the team above, if they ran five regular sprints before deciding to ship the web application, they need three weeks for a release sprint. If they ran twenty regular sprints before deciding to ship, they should also need just one three-week release sprint. To say otherwise would be to plan for work (such as bugs) to slop over from one sprint to the next.

Posted in Agile Planning | 12 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 »