If you’re wondering what a ‘sprint planning‘ is in Agile, why it’s important, and how to conduct it, you’re in the right place. In this article, we will explain everything you need to know. We will discuss the ideal timing, who should be present, how it works, what to consider, and we’ll even provide you with some tips to make it go smoothly. Ready to dive into the world of sprint planning? Let’s get started!
Agility: Further Reading
Why Sprint Planning?
The main objectives of a sprint planning session are:
Scope
Tasks
Priorities
Risks
Commitment
When to Conduct a Sprint Planning?
1. Frequency: At the beginning of the Sprint
Sprint planning is a meeting that takes place at the beginning of each sprint. As soon as the previous sprint is completed, and the retrospective is done, the team gathers to plan the next one. This frequency ensures that the team stays aligned with the goals and can react to changes more quickly.
2. Maximum duration: 2 hours for a 1-week sprint.
The duration of the sprint planning typically depends on the length of the current sprint. A common rule of thumb is to allocate about 2 hours of meeting time for each week of the sprint. For example, for a two-week sprint, the sprint planning meeting should not exceed 4 hours. This time limit encourages efficiency and keeps the meeting focused on essential points.
3. Input: Prioritized Product Backlog
The key element needed to start a sprint planning is the Product Backlog. It should be prioritized in advance by the Product Owner. During sprint planning, the team selects items from this backlog to include in the sprint.
4. Output: Prioritized Sprint Backlog
At the end of the sprint planning, the team generates the ‘Sprint Backlog’. It’s a prioritized list of specific tasks that the team commits to completing during the sprint and will present to the client during the Sprint Review at the end. It details the tasks, responsibilities, and objectives that the team must achieve.
Who Attends the Sprint Planning?
Scrum Master
Facilitateur
The Scrum Master is a key member of the Scrum team. They facilitate the sprint planning meeting, ensuring that the process runs smoothly and helping to remove obstacles. The Scrum Master ensures that the meeting is collaborative, efficient, and adheres to the time allotted.
Product Owner
Sponsor
The Product Owner plays a central role in sprint planning. They bring the Product Backlog, which is the list of product items to be accomplished, and work closely with the team to explain the needs and priorities. They assist in defining the sprint objectives and ensuring that the team works on the most important items for end users.
Scrum Team
Implementers
The Scrum Team, composed of different roles, is at the core of sprint planning.
- It includes Business Analysts, developers, and Quality Analysts.
- The Business Analysts translate business needs into concrete tasks.
- The developers write the code and implement the features.
- The Quality Analysts ensure the quality of the work by defining acceptance criteria and conducting tests.
How to Conduct Sprint Planning?
A Sprint Planning consists of 4 phases :
- Exploration
- Splitting User Stories
- Estimation
- Commitment
Objective: Have a description of what the system should do
Scenarios :
- The Product Owner presents the overall project objective.
- In collaboration with the Business Analyst, the Product Owner clearly details the requirements verbally.
- Developers ask questions to clarify unclear points.
- Developers:
- Question the proposed solution, bringing a critical perspective.
- Assess the project’s feasibility and propose a Proof of Concept (POC) if needed.
- Reevaluate Story Points if necessary.
- The Quality Analyst initiates the discussion on needs and develops an appropriate testing strategy.
Objective: Divide the User Story into Sprint-sized units for easier estimation and focus on the essential elements, following the 80/20 principle.
“Scenarios :
- Cut absolutely when:
- Developers cannot estimate because it’s too complex.
- It doesn’t fit within a Sprint.
- Cut optionally to better control the scope (the smaller the units, the more manageable they are)
- Slicing is done in consultation with the Product Owner.
How to slice ? Using the INVEST model, User Stories should have the following characteristics:
- INDRPENDANT: they should be deliverable independently.
- NEGOTIABLE : they should be removable without impacting the entire feature.
- VALUABLE: they should bring tangible business value.
- ESTIMABLE : their effort should be measurable.
- SMALL: the smaller, the more manageable.
- TESTABLE: test scenarios should demonstrate that the User Story is complete.
An effective User Story should be formulable in one sentence using the format “As a [rôle], I must be able to [action] to [objectif]”
Attention, that’s not enough!
For example: as a user, I must be able to search with flexible dates to find the flights that suit me.
- It can be further broken down into:
- … ‘n days between x and y’ …
- … ‘A weekend during a given month’…
- … ‘+/- n days between x and y’…
After identifying the User Stories, developers:
- Brainstorm the Tasks (design, development, etc.) for each User Story.
- A task should be clear to everyone. Technical design can be addressed for complex tasks.
- Determine any necessary refactorings for each User Story.
- Identify technical risks and propose plans to mitigate them.
Objective: Determine the amount of work achievable within the sprint by evaluating the effort required for each backlog item, enabling realistic planning.
Estimations are made for the User Stories that have been discussed during the previous phases. This means that the team is looking at the tasks it plans to accomplish during the sprint.
In some cases, Story Point estimation has already been done:
- BeforeSprint Planning (during Sprint Review)
- Or during the exploration phase of Sprint Planning
When we talk about estimation units, we can use two main ones:
- Story Point is used to estimate the complexity of User Stories. This helps us understand how challenging a task can be.
- Man-Day is used to estimate the time needed to perform development tasks or other more detailed activities. This helps us predict how long it will take to complete specific sub-tasks related to User Stories.
Objective: The team commits to a scope among the estimated User Stories.
Steps:
- Review the team’s capacity, taking into account vacations, holidays, etc.
- Take the User Stories in priority order until reaching the target velocity accepted by all stakeholders.
- These User Stories will make up the Sprint Backlog.
The Product Owner does not pressure the team to take on more User Stories than the team can realistically complete during the sprint.
Prototyping
Prototyping technically risky requests before including them in Sprint Planning allows the team to better understand potential challenges, assess feasibility, and reduce uncertainties.
This ensures that technical issues are addressed before committing to implementation, thus minimizing risks and promoting smoother task execution.
Empowerment
An empowered team is more likely to keep its commitments, which builds trust, motivation, and collective performance. Empowerment also encourages proactive problem-solving.
Velocity
For the Scrum Team, velocity is the capacity in Story Points to produce during a Sprint.
What velocity is:
- A derived value: It is calculated based on the amount of work (usually in Story Points) that the team has managed to complete during each Sprint. It is updated after the closure of each Sprint.
- Used to build roadmaps and plans: Velocity helps estimate how much work a team can accomplish in future Sprints. This aids in planning and prioritizing User Stories or tasks to include in upcoming developments.
What velocity is not:
- Productivity: It does not measure the individual performance of team members but rather the collective capacity of the team to deliver items during a Sprint.
- A means to judge the team: It should not be used to assess the quality of the team’s work but rather as a planning tool.
- A means to compare teams: Each team has its velocity based on its abilities, estimation unit, and working approach, making it non-comparable to other teams.
- A means to influence team engagement: Velocity is not an indicator to push the team to work faster but rather a way to estimate the team’s capacity realistically. Team engagement should be based on a clear understanding of Sprint objectives and priorities.
Tips and tricks
Sprint Planning
Estimation
The estimation scale should be defined at the beginning of the project and should never change.
- Use the adapted Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 along with a reference scale.
Tools
Define clearly the Definition of Done (DoD)
Make sure the DoD is well defined for each User Story, and that the entire team understands the criteria that must be met for a User Story to be considered completed.
Product Owner
Engage the team.
Sprint Planning Retrospective
Plan a retrospective at the end of the Sprint Planning to allow the team to reflect on the process and make improvements.
Promote transparency.
Product Backlog
Acceptance
Communication
Make sure that all important information is clearly communicated to the team, including priorities, goals, and any potential changes to the sprint.
Respect the allocated time.
Duration
Everyone should be aware of the importance of respecting the meeting duration:
- Usually, the team is eager to start the Sprint and doesn’t spend much time planning.
- The Product Owner‘s availability is not guaranteed.
Avoid interruptions
Flexibility
0 Comments