Technology, market, and environmental complexities increase day by day, resulting in increased interactions which on the one hand is a good thing, but on the other hand, it requires having a better agile methodology which will help in dealing with this complexity. We have already talked about Scrum and the possibilities it offers in one of our previous blog posts (link), here we will give an overview of why Sprint Planning Meeting – one of the events of Scrum – is crucial in the entire process.
Scrum Framework consists of the following components:
- The three roles: Scrum Master, Scrum Product Owner and the Scrum Team
- A prioritized Backlog containing the end user requirements
- Sprints
- Scrum Events: Sprint Planning Meeting (WHAT Meeting, HOW-Meeting), Daily Scrum Meeting, Sprint Review Meeting, Sprint Retrospective Meeting).
Scrum events are an important part of the Scrum Framework because they create regularity and minimize the need for meetings which are not defined in Scrum. All of the events have a fixed time period which is usually their maximum duration. The time that is allocated to one Sprint it’s fixed and cannot be changed. As far as the remaining events are considered, they may end when the event purpose is achieved, ensuring that the appropriate amount of time is spent without allowing waste in the process.
Sprint planning meeting
The Sprint Planning Meeting begins with the selection of the most important product features. This is done by the Product Owner, who presents them in front of the Development Team. The goal behind all this is to ensure that:
- The sprint goal is clearly defined;
- Acceptance criteria is clearly stated for each user story;
- The Development Team properly understands the Definition of Done “DoD”.
These three factors are of great importance, since they affect the success of the Sprint. Due to it, the Development Team should understand the product vision and develop user stories in the best possible manner to fulfill the project goal.
When it comes to the time spent on Sprint Planning, it might vary. Usually, the Sprints that are one-month long have a Sprint Planning meeting of 8 hours. As for the Sprints which are shorter than a month, this event is shorter as well.
The Sprint Planning meeting is carried out by the Scrum Master, who should ensure that everyone involved participates and understands the purpose. During this meeting the Scrum Master also makes sure that the Scrum Team respects the allocated time and they define two important things: a) the Sprint goal and the b) Team capacity.
Sprint Goal
The Sprint Goal is usually defined by the Scrum Product Owner. And as with everything else, the sprint goal gives a short description of the end results, which should be realistic and comprehensible for everyone. Usually the goals are used for reporting to those who are not directly involved in the process – the same is with the Sprint Goal as well. The Sprint Goal is used to give an insight to the stakeholders about the process – what the team is working on, how is work progressing etc., but without going on further into product backlog item (user story) in details.
Team Capacity
Before planning any activity, everyone should know the capacity of the resources they have, because the team capacity affects the time and manner a certain activity is performed. When it comes to the Scrum Team, the total capacity of the same might change from Sprint to Sprint. Before making any commitments and steps, it is wise to know the total capacity of the team for the next Sprint, taking into consideration anything that might affect the capacity such as vacations, public holidays, efforts for Scrum Meetings and time needed for all other activities during the Sprint.
WHAT and HOW?
Sprint Planning give answers to two important questions:
- WHAT we will achieve with this Sprint?
- HOW we will do it?
WHAT we will achieve with this Sprint?
Sprint Planning forecasts what will be developed during the Sprint. This is done by the Development Team, which furthermore evaluates and forecasts the functionality to-be-developed. As far as the objective is concerned, the Product Owner is the one who discusses what should be achieved, i.e. the objective, as well as the Product Backlog items leading to achieving the Sprint Goal, but only if they are completed in the Sprint. If we want all this to work simultaneously, the entire Scrum Team should understand the work of the Sprint.
The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint and past performance of the Development Team. And again the Development Team has the work of deciding on the number of items which will be selected from the Product Backlog, and even more assessing what it can accomplish over the upcoming Sprint. Sprint Planning includes crafting a Sprint Goal as well, which is an objective meant to be fulfilled within the Sprint through the implementation of the Product Backlog. Moreover, the Sprint Goal serves as a guide for the Development Team – it gives the team the reason why it is building the Increment.
HOW we will do it?
After the WHAT in the first phase of the Sprint Planning we have the HOW. The answer to this question includes filling of the Sprint Backlog with the tasks needed for complete implementation of the Scrum Product Backlog entries. There isn’t a specific time when it should be done, it is of course after the WHAT-meeting, but it can be as a part of the WHAT-meeting or completely separate. The HOW part includes the following tasks: design, implementation, test and documentation-activities.
Besides identifying the necessary tasks, this part includes estimation of the time needed for the same to be completed. Additionally, during this part the Product Owner may offer help in clarifying the selected Product Backlog items and make some trade-offs if necessary. Depending on the amount of work that should be done the Development team might ask the Product Owner to make a revision of the selected Product Backlog items. If technical or domain assistance is needed, the Development Team might also ask other people, specialized in that field of expertise, to join the meeting.
After the Sprint Planning has finished, it should give the Development Team enough information which will help them understand and decide how it will work as a self-organizing team in order to achieve the stated Sprint Goal and create the anticipated Increment.
Sprint Backlog
We can consider the Sprint Backlog as a notebook updated regularly on a daily basis. Everything that occurs during the day is recorded within the Sprint Backlog. Whenever some of the team members starts working on some activity, Spring Backlog has that information. Additionally, all of the new activities that might be added during the Sprint will be found in the Sprint Backlog as well. So, the Sprint Backlog contains information about daily tasks, carried out activities, and even all remaining efforts which defines how much work is left until the Sprint Goal is reached. In order for the team members to define whether an item is done or no, they use the Definition of Done.
The Sprint Backlog serves the purpose of a highly visible, real-time picture of the work that the Development Team has planned to accomplish, and it belongs only to the Development Team. As such, only the team members have the authority of changing it during a Sprint. The change might include adding new work and/or removing unnecessary elements of the plan, which leads to further re-evaluation and update of the remaining work to be done.
Definition of “Done”
Whenever a Product Backlog item or an Increment is finished, everyone of the Scrum Team should know that. The members of every Scrum Team must have a common knowledge of what “the work is completed” means. The Definition of “Done” is in fact a checklist of all the activities ensuring that only truly Done features are delivered, not only in terms of functionality but in terms of quality as well. The DoD may vary from one Scrum Team to another, but must be consistent within one team.
Besides the “definition of done”, the “definition of ready” exists as well. This definition serves to provide clarity to the Product Owner or the Product Owner team on what it means to create ready Backlog items. The “definition of ready” includes:
- All stories must meet the INVEST criteria
- A clearly defined user
- An estimate
- Acceptance criteria with examples
Additional items may include:
- Acceptance criteria in a certain format such as “given…, when…, then…”
- External information that can provide context such as:
- User journeys that provide context for the backlog item
- Screen mockups
- Architectural drawings, Business rules.
Scrum user stories
Scrum user stories have a focus on what the user needs/wants without going into the details on how to achieve it. To be more specific, they are in fact stories that contain a name, a brief narrative, and acceptance criteria and conditions for the story to be complete.
There are different ways of defining User Stories. This is one example of how one template might look:
As an [actor], I [want must] [action] so that [achievement] Or in a shorter version: As an [actor], I [want must] [achievement]
In this case, the user story contains three important parts: the actor, the action and the achievement.
Actor: The actor is the ‘owner’ of the user story. It is better to use a specific actor, such as “Administrator”, “Logged in Customer”, “Unauthenticated visitor” etc. Why? Because the user will understand the story easier and moreover will be able to set the user story into context.
Action: What the actor wants to do, but a difference should be made regarding the type of the action and the word that is used. Whenever the action is obligatory one we should use “must”, in all other cases “want” is used.
Achievement: This part defines what the end product of the action is viewed from the actor’s point of view.
Scrum effort estimations – planning poker
The estimation step is an important step as well, because it gives the Scrum Product Owner an insight into which entries should be prioritized and when to plan releases. So, the estimations should be as precise and honest as possible no matter of the difficulty of the work. Sometimes, it is better if the Scrum Product Owner does not attend when the Scrum Team does the estimation so any unwanted pressure to be avoided leading to not so clear estimation.
The Scrum Framework does not propose a way for estimation of the work, however what is certain is that the estimation is not normally done in terms of time, but a more abstracted metric to quantify effort is used. Some of the most common estimating methods are: numeric sizing (1 through 10), t-shirt sizes (XS, S, M, L, XL, XXL, XXXL) or the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.).
Planning Poker / Scrum Poker
Planning Poker or Scrum Poker is one of the method which can be used during the estimation process. Planning Poker® gives a more accurate estimation results because it minimizes the influence between the participants. In order to play Planning Poker® we need the following things:
- The list of features to be estimated
- Decks of numbered cards.
When it comes to the deck of numbered cards, one good example can be the deck showing the Fibonacci sequence including a zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; other similar progressions are also possible. Why the Fibonacci sequence is good? It can reflect the uncertainty in estimating larger items. When the card shows a high estimate, it means that the story is not well understood and it should be described or told into multiple smaller stories.
Rules:
- The Scrum Product Owner presents the story to be estimated;
- The Scrum Team asks questions;
- The Scrum Product Owner explains in more detail;
- If there is more than one story, then the Scrum Product Owner allocates a certain time-constraint for each story. The goal is the story to be understood in the specified time-constraint. If it isn’t, then the story should be re-written;
- Once every member listens to the story, they decide whether the story is clear or no, by choosing a card that will represent the estimation;
- Everyone shows their estimations;
- The members with high and low estimates explain their estimate;
- Estimation starts again and the game is repeated until all stories are estimated and a consent is found.
Conclusion
To sum up, Sprint Planning is important because the outcomes of it are the Sprint Goal and a plan of delivering the Increment. Additionally, the Sprint Backlog contains all the work that should be done in details, which allows the Development Team to forecast the time and work needed. As with any planning, it is the phase where all WHATs and HOW-TOs are answered. A good planning always leads to good outcomes and the wanted results.
