A Sprint Planning meeting produces the following artefacts
- A Sprint Goal which is a short description about what the Product Owner (PO) and the team have agreed to achieve in the Sprint.
- A Sprint Backlog which is a set of prioritised and estimated user stories and their respective tasks that the team has committed to in order to achieve the Sprint Goal
The team needs to have full clarity on both the above artefacts in order to deliver working (shippable) software in accordance with their Definition of Done at the end of the Sprint. So that the Sprint is worth the while of the team and worth the money the client is spending for that Sprint, each member of the team needs to understand the Sprint’s stories and the tasks included therein well. This also includes the UI designs or wireframes for each story included in that Sprint. While the stories describe the functionality, the UI designs / wireframes describe the form.
Let’s look at the Steps of a Sprint Planning meeting:
1. Review the Product Backlog
The PO starts describing the stories from the top of the backlog along with their respective UI designs/wireframes. The team usually asks questions regarding the stories being discussed which the PO answers. Once the team has complete clarity on what needs to be done to complete the user story, the team creates a list of tasks (usually technical in nature) for each user story. The QA person (if you have a specific person for this role) also mentions some test cases he would use for black box testing. However, he is free to include them during the course of the Sprint too. What is relevant and what is not can always be discussed among the team and the PO.
2. Estimate the Sprint Backlog
When the team feels they have discussed enough stories from the top of the backlog, they start estimating the same. The preferred way is to estimate stories in Story Points and use Planning Poker so that everyone is on the same page and the estimate has acceptance within the team.
Based on the team’s current velocity and the time available within the Sprint, the team makes a commitment on what stories it would complete at the end of the Sprint as per the definition of done without skimping on quality.
Now let’s try and understand a Sprint Backlog in depth so that we know the expected output from a Sprint Planning meeting. A Sprint Backlog has the following attributes:
- It is a subset of the Product Backlog
- Whatever the PO/Client feels needs to be a part of the product forms the Product Backlog. The Sprint Backlog is a subset of it i.e., it cannot include anything that is not a part of the Product Backlog. Sometimes, there is a need for some technical housekeeping for which the team can request the PO to include (and prioritise) in the Product Backlog. They can be included in Sprint Backlog too provided they are a part of the Product Backlog first.
- A Sprint Backlog requires a commitment from the team on what would be delivered at the end of the Sprint. This team commitment needs to:
- be clearly understood and agreed upon by every single member of the team and the PO too
- be achievable without sacrificing quality
- be achievable without sacrificing sustainable pace (it is okay to stretch once in a while but not every time)
So now we know what is expected out of Sprint Planning and what are the steps thereof. Let’s now consider some salient points that contribute towards a fruitful Sprint Planning
A Sprint needs to start and end on the same days (I am considering Sprints that are 1-week, 2-week, n-week long). So if your Sprint cycle is Monday to Friday, it should never change. This helps get into a periodic rhythm that is felt by the entire team. All Sprints are equal sized and this never changes. A Sprint is all inclusive. Apart from the project development, it also includes Sprint Planning at the start and Sprint Review and Retrospective at the end.
A Sprint Planning includes everyone on the project – the PO (and the client too if possible), the Team (including the developers, QA persons, UI design persons), and ScrumMaster
- Sync Sprint Plan With the Client
If the client is not present in the Sprint Planning meeting and the meeting is chaired by the PO, it is imperative that the PO syncs up with client to apprise him of what all has been committed to in the Sprint Planning. The client might have a rough idea initially as he had prioritised the backlog but this sync up would make sure he knows for sure what to expect at the end of the Sprint.
As it happens on most complex projects, there are functionalities / technologies which no one in the team might have experience with. Such functionalities require researching and building a proof of concept perhaps. For such unknowns, it is good to include a small time box within the Sprint (one or two days for example) for researching and checking the viability. This is done a Sprint in advance. Such a spike reduces the uncertainty when the team comes across implementing the functionality actually and helps them estimate the story appropriately.
There may be a rare case that the Sprint Goal that the team is chasing becomes irrelevant in the middle of the Sprint. In such a case, the Sprint can be terminated in the middle and then a new Sprint is planned. However such terminations should be exceptions, not rules. Whenever you have changes being requested to the current Sprint, they should be prioritised to be taken up in the next Sprint. Only in the extreme case should one consider terminating a Sprint in progress.
Now that we have a good hang of what a Sprint Planning (and Sprint) includes, let’s look at Five Commandments for Sprint Planning
1. Thou Shall Stay a Sprint Ahead of the Team
The PO should stay a Sprint ahead of the team grooming the backlog, making sure that the epics are broken down into user stories, arranging the UI designs / wireframes for the stories in the upcoming Sprint, and identifying stories that might need Spikes to be included in the current Sprint.
2. Thou Shalt Not Extend the Sprint
It’s possible that the team is left with an incomplete story at the end of the Sprint. They might consider extending the Sprint by a day or two to complete the pending work and fulfil the commitment they made at the start of the Sprint. This should never be done. Never, ever. Sprint delivery includes completed stories and incomplete / pending work gets put back on the backlog for prioritisation. The Sprint is never extended. This ties in with the point above of having Fixed Start and End Days.
3. Thou Shalt Not Include Extra Time
Never factor in extra time (apart from working hours) in a Sprint. PO / team might be tempted to consider after hours or weekends to meet an aggressive target or complete stories committed in a Sprint. This can be considered only in the rarest of rare cases and should never be encouraged. This ties in to the principle of sustainable pace within a Sprint. While it can be permitted for a couple of days in the project, any longer than that and the team would be setting itself up for failure and lower productivity.
4. Thou Shalt Not Add More Work
Adding more work in the middle of a Sprint is something that Agile is strongly against. The team commits to a set of stories according to their Definition of Done that makes their Sprint Backlog. That backlog should not be messed with. The PO should not try to add / change stuff that is already a part of the Sprint Backlog. Only if the team agrees can the PO swap some item in the backlog with another equally sized item provided it doesn’t derail the Sprint. Any changes can be considered in the next Sprint. But no work should be added to Sprint. However, if the team finishes early, they are allowed to pull in more stuff from the Product Backlog into their Sprint Backlog but not otherwise. Adding more work to a Sprint in target would amount to hitting a moving target and is a sure shot recipe for disaster.
5. Thou Shall Deliver After Each Sprint
The team should deliver working software as per the Sprint Backlog and the Definition of Done after each sprint. No exceptions. This should be delivered to the PO / client for User Acceptance Testing and any changes / feedback should be put back on the Product Backlog for prioritisation.
There is the concept of a Sprint 0 that is a double edged sword. It can have its benefits if handled properly else it can cause you to slide back into Waterfall. The purpose of a Sprint 0 is to:
- bring the team together and give them a high level overview of the project
- set up tools (code repository, project management, story board tool, etc.) for the project
- check tech feasibility of risky components of the project
- get UI design and wireframes done for the first Sprint
- break down epics into user stories for Sprint 1
- arrange resources like App Store developer account, servers for development / testing, emails for support, etc.
Sprint 0 should not be mistaken for a mini Waterfall wherein all stories are attempted to be defined in detail upfront, UI design completed upfront, etc. All these tasks happen Sprint by Sprint (being one Sprint ahead of the team). The focus should be on emergent design (both architecture design and UI design) during the course of the project and not everything upfront.
Though the above seems like a lot (and probably it is) but once you get into a rhythm of doing it, it becomes natural. It is similar to learning to drive a car wherein you have to do a lot at the same time – control the steering wheel, keep the foot on the accelerator, change gears occasionally while pressing the clutch, look in front, look in the rear view mirror, look in the side view mirror, be ready to hit the brakes! After some time it gets so smooth that you can do all the above (and more *wink*) with ease. Same is true with Sprint Planning. If you learn to do it well, the project execution would be very smooth.