How much to task out during Sprint Planning

Hi Amanda,

If you allow work to spill over the sprints, does this actually helps you with planning and goal setting during sprint planning?

As far as I can say from my experience, reducing the amount of work taken into the sprint actually speed up things in the long run. So if you make your plans, and you feel that this amount of work is doable in one sprint, reduce it.

I feel that you put too much focus on tasks on itself. What is important is the Sprint Goal, and other goals of Scrum Team, in radical situation scope of Sprint Backlog can change entirely in any point of Sprint, as long as these change doesn't endanger the Sprint Goal, but actually ensures achieving it.

Also, decomposing all the work in PBI may be considered as a waste, as some of it may be unnecessary to do. I think that you should decompose as much as needed and as little as possible to know what we need to do right after Sprint Planning and maybe following few days, during the Sprint, as work progress towards your Sprint Goal, you will discover what other work we also need to do, and we replan things on the go in a pace no longer than from one Daily Scrum to next Daily Scrum.

Any ideas or suggestions?

Let’s put the matter of stories and tasks to one side for the moment. What are your thoughts about planning just enough work to release a product increment that meets a Sprint Goal?

Personally, I like to make Sprint Planning simple. That is, I don't like refining to the point of creating tasks and sub-tasks, or event assigning story point or t-shirt sizes.

In short, I want to know what work can the Development Team forecast that results in a Done increment at the end of a Sprint? I like one week Sprints. If somebody looks at the highest priority story and says that it's too big to get done in a week, then we refine it.

The teams are worried that if we don't task out everything (even though we know it won't get done in that sprint), that they will forget them by the time we get to the next sprint planning.

So you have a development team that is able to accurately list everything that is going to be needed to finish a story even if that work spans Sprints?  Wow, this is the very first team I have ever been told of that can do that.  Every team I have ever worked with has uncovered new tasks when they start working or even found that some of their expected tasks are not actually needed.  To hear of a team that can list out the exact work that is going to be done for the coming weeks is very impressive.  

Sorry for the sarcasm but this is how I'd approach it with the team.  I would actually go back to "done" stories as examples and ask them how accurate they were.  And if your team is afraid of forgetting work that needs to be done on something that they are actively working on, I'd be really scared. That is some pretty serious issues with short-term memory. 

OK, this time I really am sorry for the sarcasm but I just couldn't help myself.