Forums

During our sprint planning meeting the team decides how many stories to take on for the sprint, breaks stories down to tasks and then jointly estimate the tasks in ideal hours. No tasks are currently assigned/taken on by developers at the sprint planning.
This has the advantage of emphasizing that we take on the work as a team, not as a group of individuals that are only responsible for his/her tasks during the sprint.
However, creating a plan for the sprint is more difficult as you could end up with a lot of work that is depending on a few individuals, such as a database developer or QA engineer. The team is responsible for making a plan on how to deliver the stories in the sprint and this plan need to take into account the availability and workload of developers.
Would it be better to have developers sign up for tasks during sprint planning to make bottlenecks and dependencies visible? How do you do this in your sprint planning meetings?

I'll of course let the team decide how they want to track their progress and plan their work but I am still interested in your thoughts on this.

Thanks
Fredrik

Fredrik,

I coached a team that had similar challenges. The way that team solved that was to do the following:
* Towards the end of sprint planning, the dev team looked for any "critical paths" or "potential bottlenecks" in the Sprint plan. The team mark any tasks that met one of those two conditions with a red asterisk. People would generally start work on the critical path type tasks first(or early) so as to reduce the bottlenecks. The team would also keep a close eye on the critical path as the sprint progressed.
* (This team also did this)While I strongly prefer people to sign up for tasks as the sprint emerges, I think it's generally a good practice for developers, at the end of Sprint planning, to sign up for a task or two so everyone knows where everyone is starting.

In my experience, signing up for more than about two tasks early in the sprint usually creates more bottlenecks rather than less, as everyone views it as a static plan that cannot be changed. As such, people end up saying "Well, I can't work on task C because so and so is signed up for task B and he's still working on task X".

I have some more material on Sprint tasking that you might be interested in here:
http://www.scrumcrazy.com/Sprint+Tasking+Tips

Hi Charles,

Thanks for your ideas. I'll suggest your idea about marking critical/bottleneck tasks. A minority of tasks should fall into this category and if there are too many that will be an indicator that we'll have problems delivering the stories.

A question about tip #22 in your sprint tasking tips. How does the idea of calculating available capacity and tracking remaining time work when pair programming? I guess you want to decide if you want to/should pair on a task when you start working with it, and not at the sprint planning. If the pairing is done for teaching/mentoring purposes the time for an 8 hour task would double from 8 to 16 hours, rendering the capacity planning at the sprint planning useless. What's your take on this?

Fredrik,

If you know at Sprint Planning that you will pair, then estimate the task in person hours (See tip #13 for more on how to estimate paired tasks)

If a dev later decides to pair, then they should change the task estimate as soon as they know that the number of person hours will be materially higher.

One of the purposes of the capacity planning at Sprint Planning is to create a "capacity line" on your burndown. By changing the task estimate as soon as the change is known, it will impact how the actual line in relation to the capacity line, thus reflecting the current reality.

I don't see how any of these "changes to reflect reality" render the Sprint capacity planning useless. I think these changes increase transparency on reality.

I should also mention that the tips in that article are mainly for "Shu"/Beginning level teams. It sounds like your team is in that "neighborhood," so the advice should probably still prove useful.

Charles,

My point with "useless" was that if it's unknown whether members will team on tasks the estimate can be off by 100% during sprint planning. The most important thing though is not to have a perfect plan to start with but to inspect/adapt during the sprint so the remaining work is visible. I think your suggestion to increase the estimates when members decide to pair will work for us and will suggest we try it.

Thanks for your ideas.

Fredrik,

You're welcome. I'm happy to help.

The other thing your team can start to observe is the rough amount of time that pairing happens, and then do new Sprint planning with that in mind. For instance, the team could plan to pair about 20 hours in the next sprint, and take that into account in Sprint Planning. You are correct -- the point is not to create a perfect plan - but one that is based on "what we know now," then inspect and adapt forward as the sprint and future sprints progress.

Best of luck!