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.