Sprint Planning in practice
Hi
Over the weekend I tried to quickly put together a visual presentation of how to run Sprint Planning. It's still very rough and very open to input and changes.
The idea is to use it as a presentation with new teams, but also have it work as posters for existing teams. I would really appreciate input.
- Ideas are still rough so I'm open to any input.
- If there is something you don't agree with, you are welcome to say so, but please include solutions.
- Commenting on the presentation is turned on. Try keep general discussions on the forum and then add comments on the presentation if you have ideas or input to specific points.
- I tried to keep it vague so not to say you have to do it a specific way. If there are ideas on how to do it another way then please let me know.
- I would love input on variations on Agile games, facilitation techniques, ice breakers, techniques that can be added. (for example Planning Poker is not the only way to estimate)
- Roles also have not been defined to actions yet. Green dot are placeholders.
- It's still WIP with text missing.
- Need to resize the document to work for printing and A4's.
I've done something similar in the past(included on first slide as demonstration), but that was more specific to the Scrum Guide, so it doesn't cover the exact aspect of HOW to run Sprint Planning and which techniques to use. Again, would like to keep it open and give options, rather than saying one way is the only way.
I'm also looking at doing the same process for the other events, so feel free to give ideas for those before I start on them.
Might it be better to do estimation/planning poker in advance of Sprint Planning, so items are "ready" to be worked on?
Do you think a case can be made for including the Definition of Done as an input to Sprint Planning?
I'm going to agree with @Ian Mitchell on the estimation. I have found that coming into Planning with a set of pre-estimated items makes things much easier and usually faster. The more refinement that can occur before hand, the more successful the planning sessions. On Slide 13, the bullet for Detailed Discussion sounds exactly like refinement to me. Waiting until Sprint Planning for that kind of discovery is too late to deal with any issues that could become impediments.
I'm also not a big fan of your capacity formulas. But that is just my opinion. Formulas like those always trigger PTSD to the days of GANTT charts in Microsoft Project. I track that kind of information but I look for generalizations in the data. In my experience the existence of these kind of formulas will often become measures to which people are held accountable. It is too easy to start dividing those by the number of people and everyone is going to be held accountable for a specific number of story points instead of measuring the team on the amount of valuable work they are producing. And when you are using story points as your guide you are doing everything based upon guesses. But I've said enough about that.
I'll try come back to this later and go through it again.
Neal, I entered several comments into your deck.
I also agree with previous observations around estimates. It is difficult for a PO to prepare to make an offer to the Dev /team, or for them to discuss a viable Sprint Goal, without completing some level of sizing beforehand.
Had to change the document's size, which stretched items. Had to recreate it in another document and hid the old slides.
I've also updated to include the Scrum Guide text in the slides, but simplified the slides in general.
------------------------------------------
Might it be better to do estimation/planning poker in advance of Sprint Planning, so items are "ready" to be worked on?
@Ian Mitchell Agreed. Updated slide 3 with "Product Backlog Refinement Item Estimates". Removed estimation from the Sprint Planning. Thanks!
Do you think a case can be made for including the Definition of Done as an input to Sprint Planning?
@Ian Mitchell Definitely! Added to slide 3 as an input.
I'm going to agree with @Ian Mitchell on the estimation. I have found that coming into Planning with a set of pre-estimated items makes things much easier and usually faster. The more refinement that can occur before hand, the more successful the planning sessions. On Slide 13, the bullet for Detailed Discussion sounds exactly like refinement to me. Waiting until Sprint Planning for that kind of discovery is too late to deal with any issues that could become impediments.
I'm also not a big fan of your capacity formulas. But that is just my opinion. Formulas like those always trigger PTSD to the days of GANTT charts in Microsoft Project. I track that kind of information but I look for generalizations in the data. In my experience the existence of these kind of formulas will often become measures to which people are held accountable. It is too easy to start dividing those by the number of people and everyone is going to be held accountable for a specific number of story points instead of measuring the team on the amount of valuable work they are producing. And when you are using story points as your guide you are doing everything based upon guesses. But I've said enough about that.
Thanks for the input. Agree on estimation happening before the Sprint.
Regarding the formulas. I can see what you mean. Timothy Baffa mentioned something similar in the document. So would you suggest using the average velocity as a reference for the team, but they then decide their own work based on Story Points they assigned to each item. Makes sense and keeps it simple. Keen to try this out.
@Timothy Baffa
Thanks for the input in the document. Good points you are making! I've responded to those in the document.
I added some comments to your slides. I like the overall presentation idea and I am picking up a few things myself from the discussion. Thanks for allowing us to participate. I look forward to seeing the final product and possibly hearing from you on how it is received when you use it.