Sprint planning - developers signing up for tasks?

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!