Agile is a great tool for products (or projects) that are continuously changed due to the market, customers, technology or dependencies. An adaption to changes is in the DNA of the agile mindset.

Traditional approaches are based on the feeling of safety. We have to think thoroughly about everything that might happen. That was usable fed decades ago, however, our era is much more dynamic. The world is globalized, technologies change exponentially (think about Moore’s law).

This is a fundamental thought for a change of our logical approach of having THE PLAN.

We cannot have the plan anymore. Instead of that we have to do planning continuously.

That is the reason for working in short sprint iterations (see Scrum) which start with the Sprint Planning as the first ceremony of the sprint. Such sprint planning is repeated every few weeks. As the team implements requirements planned for the current sprint, the product owner can prepare the next sprint (and release plan as well).

Goals of the Sprint Planning

1. To agree with the team and the product owner on the scope which needs to be developed in the sprint.
2. To detail and break down requirements into tasks and distribute them appropriately within the team.
3. To validate a team capacity and update the scope of the sprint based on that.
4. To commit to work that can be finished.
5. To create a Kanban board where sprint requirements and subtasks necessary for their implementation will be placed for transparency and self-organization.

Who?

Product Owner

1. An introduction of sprint goals.
2. An introduction of top requirements that have to be developed in the sprint.
3. PO ensures that requirements are fulfilling the team’s Definition of Ready before the sprint planning.
4. Participates in the following discussion about requirements and acceptance criteria.
5. Update the order of requirements based on information discovered in the sprint planning and team capacity.
6. Commitment to the planned sprint backlog.
7. Communication of planned scope with stakeholders and other product owners (in case of large systems).

Scrum Master

1. Arrange the planning meeting, The Scrum Master invites necessary people, prepares the agenda of the meeting and environment for the meeting.
2. Prepares Kanban board and post-its necessary for it.
3. Prepares selected metrics so the team can plan work better than in previous sprints (sprint burndown charts, velocity chart, the Definition of Done, the Definition of Ready, etc.)
4. Create a new sprint in an electronic tool so the team can fill the sprint backlog in the sprint planning.
5. Prepares tool for capacity calculation (excel, the table on flipchart paper, or with another tool). ScrumDesk supports capacity leveling and calculation as well.
6. Moderates sprint planning meeting and take care of the timing.
7. Synchronizes dependencies with other scrum masters if necessary.

Team Members

1. Break down of the requirements into subtasks (max. 1-day duration) according to Definition of Done.
2. Estimation of tasks.
3. Identification of dependencies and blockers.
4. Update total scope of the sprint based on capacity, dependencies, and blocker identified.
5. Commitment to the sprint backlog.
6. Finalize physical Kanban board.

Agenda

Sprint planning agenda

Capacity calculation

The team is responsible for a pull of so many requirements that the team is able to finish in the sprint timebox. A simple table might be used for sprint capacity calculation. If team members have assigned tasks in the planning session, the capacity can be calculated per team member. Some teams, however, prefer to not assign tasks in the planning and rather work according to an order of requirements defined by the product owner. In such a case, the total capacity of the team can be considered.

A very important aspect of capacity planning is to consider 6 hours per day, not 8 hours as we are used to. The reason is simple, based on experience, a man is able to finish a work of 6 hours per day. 2 additional hours are usually spent in some other activities, i.e. meetings, emails, etc. In Agile, we prefer to deliver our promises and therefore we rather promise less, but be trustworthy, than just give promises we already know are just promises. Some roles plan even less than 6 hours, i.e. UX, testers, ScrumMasters or people who support more teams at the same time.

Capacity calculator table

It is easy to calculate capacity by every team member using the post-it. The first number represents the total assigned work, the second number indicates the total availability of the team member.

Sprint capacity calculation

The expected outcome of the sprint planning

• Kanban board should be ready at the end of the sprint planning and available to everybody.
• The sprint scope is committed, dependencies identified and greed with other depending teams.
• Stakeholders are informed about the planned sprint scope.
• The capacity of the team has been considered.

Sprint task board (an example)

Checklist

1. Unfinished items from the previous sprint are either in the backlog or in some iteration.
2. The previous sprint is closed in an electronic tool and on the physical board as well.
3. Sprint backlog items fulfill the Definition of Ready.
4. Sprint backlog items are ordered appropriately.
5. Sprint backlog items are broken into subtasks according to the Definition of Done based on the item’s type.
6. Dependencies are identified and agreed upon with other parties.
7. Tasks are not longer than 1 day.
8. Tasks are described by the title which describes an activity that needs to be done. The title is not very general.
9. Tasks are optionally assigned to team members as well.
10. The team checked the team’s capacity and updated the sprint backlog according to the capacity and velocity of the team.
11. Kanban board is updated. In physical and in the electronic tool as well (if used).
12. The burndown chart is drawn.
13. ScrumMaster started the sprint in the electronic tool.
14. The team is informed about the start of the sprint so they can immediately pull tasks to develop.
15. The next sprint is created by ScrumMaster in the electronic tool so the Product Owner can start planning the next iteration from the next day of the current sprint.

How ScrumDesk supports sprint planning?