Get certified - Transform your world of work today

Close

Should Teams Identify Tasks During Sprint Planning?

22 September 2017

Hemant Kothiyal
United Health Group


I am sure that most of you require that your team identify tasks during the sprint or iteration planning. But is identifying tasks worth the effort? Don’t you think teams can identify tasks daily during the iteration? Still, it’s true that identifying tasks late in the sprint may lead to more issues.

Based on my experience, I consider the following points about identifying tasks during the iteration:
  • To minimize the effort during planning, we create a template for user stories that includes a set of common tasks.
  • If the team does not identify tasks earlier, it may identify something necessary late in the sprint, which can cause problems.
  • However, no matter how hard the team tries, it won't think of everything up front.
Importing tasks and deleting them later, if they're not required, is not the purpose of sprint planning. Our main challenge remains whether your team should identify tasks during sprint/iteration planning.

After reading various writings by Mike Cohn, and in particular his blog at Mountain Goat Software, I finally understood the purpose of sprint planning: It is to not only select the right story but also the most important features and functions to deliver, and the right number of them. A team can do this without considering everything right from the beginning. Team members need only to consider the following areas:
  • Big tasks
  • Tasks that require a fair amount of coordination, either between team members or outside the team
  • Tasks that are on the critical path
  • Initial tasks with a lot of uncertainty
I have also found that if we keep the team busy with identifying all the tasks during the sprint planning, instead of planning for complex and big tasks, the teams will think of planning as a waste of time.

I would like to keep this discussion going and hear about your experiences with planning tasks.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (5 ratings)

Comments

Rex Lester, CSM, 9/27/2017 9:59:38 AM
I sort of agree. When a team is new I tend to focus their efforts on understanding stories and let the team decide how to deliver them.
Once things settle we may start to task out User Stories (or at least understand the basic tasks), but this is a transitionary step giving us some indication of the flow.
We can then move to a more Scrumban/Kanban approach with a focus on flow and lead times.
Obviously, every team is different and the approach will differ for different products, context and technology stack..

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe