Couple of question around Sprint Planning
After reading the Scrum Guide, I can understand that planning should be split into 2 parts;
For the first part "What can be done this Sprint", I can understand that the Scrum Team creates the Sprint Goal - but then to create the Sprint Goal, I would assume they should forecast which Product Backlog Items they can work on in the next sprint.. is this correct? The phrasing of the 2nd part seems to suggest this
The second part "How will the chosen work get done", I fully understand that chosen stories will decomposed into "work item" (or Sub Tasks if we're using Jira).
It says in the guide "Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less", this seems to suggest that not all of the PBIs are decomposed into work items.. is this correct?
I've read books that seem to suggest the team should go through a cycle of:
- Decompose a PBI to work items
- Can the team commit to all the work items the team have created in the next sprint?
- If yes, go to step 1
- If no, take the PBI and work items out the sprint
I like the method above, since the first part seems to be a rough, "yes, given our velocity and capacity, it looks like we can do these PBIs" and the second part being "after working out the step-by-step parts, we don't think we can do all of the PBIs"
but then to create the Sprint Goal, I would assume they should forecast which Product Backlog Items they can work on in the next sprint.. is this correct?
A sprint goal is not the same as all the stories in the sprint. A sprint goals can be "have a single signon feature", the sprint backlog should contain PBI's to deliver this sprint goal, but may contain other items even unrelated to the sprint goal as well. Also, the sprint backlog does not have to be complete yet, work may be added later on to deliver the sprint goal
this seems to suggest that not all of the PBIs are decomposed into work items.. is this correct?
Well, it suggests that you might need to handle emerging work, not thought of at sprint planning. But also, PBI's might not be ready yet at sprint start and might need to be refined during sprint
Can the team commit to all the work items the team have created in the next sprint?
You commit to the sprint goal, not allt he work items in the sprint!!! A very common misconception. Workitems in the sprint are a forecast, not a commitment!
So, in the first part of sprint planning "what will can be done this sprint", what actually occurs besides creating a sprint goal? Or is that pretty much it for part 1?
My view of Sprint Planning.
- A Sprint Goal is created,
- items are pulled from the Product Backlog into the Sprint Backlog,
- discussion occurs about whether items in the Sprint Backlog support the Sprint Goal,
- items are decomposed enough to ensure that 1-2 days of work is identified,
- more discussion around the Sprint Goal and Sprint Backlog to determine if this is satisfactory to everyone,
- any additional modifications made to Sprint Goal and Sprint Backlog
- start the Sprint
These items do not even have to fall in that order. For example, the morning of the Sprint Planning a critical bug is reported in Production. This needs to be fixed as soon as possible in order to protect data integrity. I would coach my team that the bug should be pulled into the Sprint Backlog immediately and it is one of the items decomposed to show work for day 1-2 of the Sprint. Then they should look at the Product Backlog to craft a Sprint Goal based on items that have been previously refined. Not everything in the Sprint Backlog has to support the Sprint Goal and sometimes there can be something immediately more important than the next increment of value for the Product.
My suggestion is to stop looking at Sprint Planning as a multi-part event and treat it holistically. Everything has to occur during the event but not necessarily in a specific order. You are trying to apply process where process isn't necessarily applicable. I realize that some organizations/teams/people will perform better with procedural basis. But I have found that even those people can appreciate the process if they understand the purpose. Let the people involved in the activities determine any process that they feel is needed in order to accomplish the goal.
After reading the Scrum Guide, I can understand that planning should be split into 2 parts
Which version of the Scrum Guide are you using? Sprint Planning has not been split into 2 distinct parts since 2013. Since then there have been two topics which ought to be addressed.