If you plan a trip, you will think of where you would like to go (what is the destination) and how would you accomplish it. If you plan to renovate your house, you will have to decide what do you want to renovate and also how would you accomplish it.

So, if its sprint planning (for next 2-3 weeks) then you need to decide “what” you will try to accomplish in that time and also “how” will you get there. In my opinion, both aspects are important (when you pan anything!).

I have come across different teams who have approached planning differently. First type of a team is where the team members just look at the backlog, decide which stories they would be able to commit during the sprint, each member subscribes to a story or two and that’s it! Sprint planning is done. Then the team members go back to their desks, may or may not create tasks. Even if they break it into tasks, its done individually by each developer.

The other type of teams is where the team members collectively go through each story, one at a time, briefly recap what the story’s intent is and have some discussion around what all work (aka tasks) that might be needed to convert the story into working software, 2 weeks from now.

I see some advantages in the 2nd approach.

1. There is a shared understanding of entire sprint’s goal among the team (and not just my story)
2. Since multiple brains synchronously try to work through the work and issues / risks that the story may have, it reduces the chances of discovering surprises or much more work in middle of sprint (together we are supposed to be more smart than any one of us! 🙂 )
3. Even if I may need some help in middle of sprint from others, they would know the context

So, I am in favor of doing some discussion about figuring out tasks which might have to be done for converting story into working software. And my experience is that teams doing such planning rarely discover surprises in middle of sprint.

Although, you don’t have to get into precise task breakdown. It won’t be worth it. Also, for some stories which are very straight forward / simple, this need not be done. But especially for stories which are complex or something new or first time for us, then its worth spending more time together.

Whether we should estimate tasks into hours or not, depends. When the teams are new to scrum and are unsure of their commitment during sprint, it might be worth having rough task estimates. It helps to –

1. Check once more that team is not picking work more than their available capacity (when you don’t know velocity)
2. And to validate user stories’ size estimates (bigger ones should show work than relatively smaller ones)

As the team matures, this can be stopped (I mean estimating tasks in hours). It’s for teams to decide “stop doing it” or “continue doing it” It’s still worth doing tasks discovery together, collectively (may not be for straight forward stuff).

–  चिंगुडे