While doing scrum when it is time to do poker planning - during Story Time or during Sprint Planning? If it is during Story Time, then the only thing to do in Sprint Planning is to select stories for Sprint Backlog and write down tasks for each user story?
2 Answers
I guess, by "Story Time" you mean "Product Backlog Refinement" activity.
By my opinion, it will better to make estimation two times: during Story Time and during Sprint Planning. It is ok, because levels of these estimates are different
During Product Backlog Refinement/Story Time your Team makes estimation for high-level planning (such as Release Planning and prioritization of Product Backlog Items). Despite the fact, that accuracy of this estimation is low, Product Owner should know these rough estimates (for planning Release and making prioritization of Product Backlog).
During Sprint Planning, after decomposition of Product Backlog Items (which your Team selected for current Sprint) to tasks, Team should make estimation of these tasks. It is necessary for low-level planning. First of all, accuracy of this estimation is much more higher [that accuracy of Story Time estimation]. Only with high accuracy estimation your Team may make well detailed plan of Sprint.
Another reason for estimation during Sprint Planning: results of these two kinds of estimation usually don't match. It's mean, that Team may take more PBI for current Sprint (or reduce already selected) after Sprint Planning estimation.
Also, take a look at this question: Why use both story points and hours?. There are several answers, that explain why it is good practice to make estimate two times.
answered Jul 17, 2015 at 17:41
I gave Sergey's answer a vote, solid ideas.
I think Sergey's answer works well at smaller scale, in an Enterprise class program or multi-scrum team program you might have a little more success if you bring in Release Planning as a formal activity and do the majority of your work in the Backlog Refinement (Story Time) meeting. Here's why-
So it would go, Release Planning - Backlog Refinement - Sprint Planning
Release Planning: This is where you are working at the high level. Stories may still be in "Epic" level detail and you are just trying to ensure you are not planning more than say 150% to 200% of what could realistically fit in a Release (with 2 week sprints, 3 months releases are rather common). At this stage you are doing more what we call "T-Shirt Sizing".
Backlog Refinement (Note, turns out "Grooming" has overtly personal connotations in some languages so I try not to use it) This is where the real work is done. The goal of Backlog Refinement is to ensure that Sprint Planning can focus on just the details of a specific sprint. In the BR meetings you would be doing three things. 1- Decompose "Epics" to stories, 2- Refine Stories to "Definition of Ready", 3- Estimate.
1- Decompose: You need to take your higher level, less detail stories and decompose them down. An Epic is almost always many user stories. This is a classic story splitting exercise and I recommend starting a new question if you want tips on this.
2- Refine Stories: I've taken to use the term "Definition of Ready" for this. Where "Definition of Done" defines if a story meets the technical and business goals of a story, "Ready" indicates that the story has all the data a development team needs to execute on the story. There should be a clear and written definition of this.
3- Estimate: I recommend that in the Backlog Refinement you are doing final estimation of the "Ready" User Stories. The reason for this is the Product Owner needs to know what the Cost / Level of Effort is, so that they can compare this to the Business Value (POs should be estimating value just like Devs estimate Effort, that's a whole other topic though). The PO then can rank order the backlog based on a balance of Value vs. Cost.
If you wait until Sprint Planning, then you're probably only working based on Cost and not Value.
Sprint Planning: Sprint Planning then becomes the final fail safe and the detail planning session for the sprint. The stories are all "Ready" so there should be minimal discussion of What and Why the story is being built and focus would be on "How" it will be built.
If your stories are decomposed far enough, then you don't even need to create tasks. If you are not to that evolution of team yet, then doing quick estimating on tasks can be helpful to make sure the team is capable of completely the work they commit to.
Advanced Team Tip: Don't over estimate. - It is better to be a little under on your commit then over. Because you have a well groomed backlog, with "Ready" and estimated stories, then if you complete all your committed stories you can just reach to the top of the backlog. Of course the key here is that you've done all the work in the Backlog Refinement.
answered Jul 17, 2015 at 18:22
