When a developer starts work on a new piece of code or application for a hobby project, they generally have a rough idea of the design and how long its going to take. Scrum has taken a pragmatic approach and designed the sprint planning meeting to fit exactly that; a dialog of essentially the what's and the how's.
The time within a sprint is fixed based on the iteration length, however people’s time per iteration can change based on holiday and having resources allocated elsewhere. In order to scope out what PBIs we will put into the sprint, we need to calculate how much time we have to work with.
Assuming you have:
- 5 days in your iteration.
- 8 hours per day per team member.
- 3 team members.
- 1 team member is on holiday.
Then you have 80 hours of potential time this sprint to burn down tasks. A general rule on previous projects is that people are not machines and are not productive for 8 hours a day. Cutting this value down to 5 productive hours a day means you have 50 hours of potential time, it may look bad on your spread sheet but your project is more likely to succeed because of it.
Before a sprint can begin, a team needs to know what is going to be worked on. At the beginning of the meeting the product owner should bring in the prioritised backlog of work and work with the team to bring items into the sprint. This dialog needs to happen for two reasons:
- So the product owner communicates the priority of the tasks and what order they should be completed in.
- So the team can negotiate re-ordering tasks to tackle tasks more efficiently, usually because of technical reasons.
Exploring the latter point further, a common scenario is:
- A solution comprises of multiple systems, a frontend and a backend.
- The business priority puts the frontend system first.
- Data can only be displayed on the frontend by using the backend.
- They both need to be completed for go live.
The options are:
- Create a throw away tool to push data to the frontend.
- Implement a small slice of the backend.
So even though the business priority puts the frontend first, its more economical from a technical perspective to reorder some of the tasks. This is what the initial part of the sprint planning meeting is about, optimising the way the team will work over the sprint and providing the best value possible to the business.
The last part of sprint planning is the estimation, which involves:
- Picking a PBI from the top of the prioritised list.
- Breaking it down into tasks.
- Assigning hours (estimated) to those tasks.
What you will find during this is a vast about of discussion which will encompass business logic, lots of conceptual design, some logical design and snippets of physical design. This entire dialog drives and shapes what will happen in your sprint, so its important to strike a good balance between allowing the team to communicate and time boxing the session so the team doesn’t burn out.
After the team is satisfied about what the task involves, an estimate of the effort involved in hours should be assigned. All team members should pick a number, either on cards or their fingers and come to a consensus after a little more discussion. A good rule of thumb for the size of the tasks is that they should be small enough to be completed within a day; smaller tasks drive better more accurate estimates.
It’s important that the product owner is available during this in case the team has questions about solutions they believe need approval from the business. They can also assist as an expert in the domain of the project along with business analysts during discussions around business rules and logic.
Begin your sprint
Once you have estimated enough tasks such that your availability figure is exceeded you are ready to begin your sprint.