When we say “Sprint Planning”…?
Sprint Planning is an activity that allows us to set short-term goals and plan to achieve these goals in a collaborative way. As a result of reaching these short terms goals we expect to reach our long-term Product goals with feedbacks. It also serves the Agile mindset’s perspective of delivering the right value through short iterations and frequent feedback loops.
In this article, I tried to prepare a content in form of a guide that teams can use in their Sprint Planning, and I wanted to create a resource that they can use when they want to look back and remember. I will try to summarize the Sprint Planning event and some other details by 5 main topics and the pages from the guide that I prepared. Have a nice reading :)
Let’s start with purpose of the Guide and article.
Sprint Planning is a meeting involving the entire Scrum Team to collaboratively decide what work will be taken up for the Sprint/Sprint Goal and how the work will be done. The event needs some inputs and have some outcomes which we get at the end of the meeting. I tried to show these inputs and outcomes on the illustration.
Also, you can see the time box and attendees of the meeting below. As you see, time box of the Planning event depends on the lenght of the sprint. I know sometimes these durations seems long to the teams but we should not forget that every meeting has own purpose in the Scrum Framework, off course we can adapted the durations to our teams with considering the reasons behind it.
Sprint planning event should start with an “Ordered” Product Backlog and to have an ordered and ready Product Backlog, Refinement activity is a good practice. That is why I wanted to add some information about “Product Backlog Refinement” too.
Product Backlog refinement is the informal session to make the Product Backlog ready for the Planning session.
- Breaking down and further defining Product Backlog items into smaller more precise items.
- Adding details, such as a description, order, and size.
- Giving estimation.
- Getting information from the developers should be the topics of this meeting.
Additionally,
→ The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.
→ PO and the Developers (only topic related ones can be enough or whole team is okay too) arrange and attend this meeting.
→ It shouldn’t take more than 10% of the developers time in the sprint. (It is not written on the current Scrum Guide any more but we can say that it may continue to use as a good practice)
Let’s take a look at the topics that we need to discuss in Planning event.
3 main questions, Why, What and How can help us to make our planning sessions more structured.
- Why is this Sprint valuable?
- What can be Done this Sprint?
- How will the chosen work done?
PS: The more the Developers know about their past performance, and their Definition of Done, the more confident they will be in their Sprint forecasts. But, in any case these are only the estimations!
PS1: The Scrum Team may invite other people to the meeting to receive technical or expert advice.
PS2: If this need becomes permanent, inclusion of this competence in the team can be evaluated.
At this point, I believe that it can be helpful to know some details about Product Backlog and Sprint Backlog as well. Here is a quick reminder.
One of the main objective of Sprint Planning is making a plan to achieve the goal that we set. So, I want to share some details and examples of Product and Sprint Goal to explain it better.
Also, to be honest, in practice this part is generally most challenging part for the teams. Rather than setting a goal, just picking some items from the Backlog may seems more easier. But setting a meaningful goal can trigger more than one thing on the team. It can be helpful for teamwork, motivation and make easier our decision making during the sprint.
Items in the Product Backlog should be selected to achieve this goal. And this Sprint Goal is a commitment by the Developers. Motivates the team to find new ideas for reaching this goal. One of its aims is to increase cooperation rather than individuality in the team. In line with this goal, the team can decide together with the PO how to proceed in additional work or interuptions during the sprint. No changes should be made that would endanger Sprint Goal.
Here are the examples,
While working with the Scrum Framework, we all come across areas which makes sense in theory but hard to implement on our process or product. We are not alone, so I want to add some anti-patterns that most of us face with. If we aware of them , we can keep an eye on them and try to improve them:) Awareness is the start point of the changes, right?
Finally, I want to share a facilitation technique which can be used for Sprint Planning event. I tried to write step by step but you can always check the Liberating Structures web page for the original version of this technique and usage areas.
And just a kindly reminder for all of us, please, do not forget to observe the team, every team has their own way of difficulties…
While I was preparing this guide and article, I use many resources and also my experience. You can see the references below and use them to get more information. I hope it can help you somewhere at some point :)
References:
- Scrum Insights for Practitioners — Hiren Doshi
- Scrum Guide: https://scrumguides.org/scrum-guide.htmlhttps://www.scrum.org/
- Wise Crowd: http://www.liberatingstructures.com/
- https://medium.com/the-liberators/examples-of-real-sprint-goals-670f917ba2cd
- https://www.scrum.org/resources/blog/20-sprint-planning-anti-patterns?gclid=Cj0KCQjww_f2BRC-ARIsAP3zarEr6DaR8mn0JziPCrg7YiE52f-wm_SrervH5gzTRBWB26UXu8YUDYQaAqYoEALw_wcB
Thank you,
Seda
