Skip to main content

Sprint planning - developers signing up for tasks?

Last post 11:46 am October 16, 2012 by Charles Bradley
5 replies
05:34 am October 12, 2012

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.


11:45 am October 12, 2012


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:

05:08 am October 15, 2012

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?

01:12 pm October 15, 2012


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.

04:08 am October 16, 2012


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.

11:46 am October 16, 2012


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!

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.