Technology runs, market complexities increase and this results to the rise of interactions required by a business in order to adapt to its environmental changes. It has been multiple times explained how a better agile methodology can assist you into dealing with complexity and what are the benefits of Scrum into a business. To wrap up the components of Scrum, the framework consists of the following:
- The three roles: Scrum Master, Product Owner
andthe Scrum Team
- The Backlog
- The four Scrum Events: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
The Scrum Events is the core aspect responsible to bring all roles involved into interaction, so the Sprint gets started and Backlog items get Done in order to achieve the goal set. The former is fundamental in the agile methodology as they secure regularity and tend to eliminate the need for meetings in the middle of the process and without warning.
The Sprint Planning Meeting
3,2,1…Go! The start of this meeting is the official start of the Sprint. Scrum Master, Product Owner
Part One: WHAT?
Whilst the overall planning is a collaborative effort between the Scrum Master – facilitator of the meeting – and the Product Owner, it’s the latter’s duty to clarify to the Development Team the most important product features that they will work on. He will be the one responsible to review, select and present the highest priority Product Backlog items and ask the team to forecast and evaluate the functionality that will be developed. It is common for this part of the meeting, to have members going back and forth to the Product Owner with clarifying questions that will drive away uncertainty, define work and effort needed to meet their sprint commitment.
Closing this part of the meeting, it’s the team’s turn to compose the sprint goal within a one-sentence description of the overall end result they target to achieve. Having this realistically defined, the questions that will follow later about depth and breadth will be answered directly considering the level that they tie directly to the goal. If the questioned work doesn’t seem related, then it needs to stay out of the sprint. Last but not least, as with all the goals set, this can be used for reporting to the stakeholders involved what the Development team is working on and what they aim to accomplish.
Part Two: HOW?
Now imagine the team is about to attend a Relay race. The two coaches -Product Owner and Scrum Master – have accommodated the team’s training and preparation for the race by clarifying rules and strategy. They have given the team the explanation needed and it’s now the runners turn to decide how they will pass the finish line successfully with the higher score possible. It might seem a too simplistic similitude, but the HOW session consists of the following major parts: design, implementation, test and documentation activities.
The team has identified what needs to be achieved and will now start decomposing the Product Backlog items into tasks along with their estimation in
Similar to the rest of the events as part of the sprint, the time allocated is fixed and usually represents the maximum duration that they need to last. The planning meeting of a common four-week sprint is usually set to last no more than 8 hours. As a general rule of thumb, the total length of the planning meeting should be the result of the number of weeks your sprint is about to last multiplied by two hours. Not a strict rule to follow, as it is common for experienced teams to finish such a planning meeting in noticeable less time than the time estimated on the Scrum Guide.
How to Prepare
Prior to the Sprint Planning meeting, the Product Owner should:
- Verify stakeholders’ priorities. If they have changed, it is better for him to be aware and take it into account when setting up what needs to be achieved within the next Sprint.
- Refine the Product Backlog, a practice also known as Backlog Grooming or refinement. Having a healthy and prioritized Backlog sets the stage for the Sprint Planning. Even if it is not yet an officially accepted scrum event, many organizations nowadays consider it as a critical step that improves speed and efficiency. Why not giving it a try adapting it in your Sprint too?
- Check the Product Roadmap, so he picks the most appropriate features to get delivered.
- Know the Capacity but don’t fill it, be aware of everyone’s schedule for the duration of the sprint and leave some spare room for any unforeseen items that might come up.
- Ensure the definition of ready is clear to the Development team, so you provide them clarity and create the path to deliver in a predictable way.
- Specify Acceptance Criteria, or in other words define the conditions that a product must satisfy to be accepted by the end user, customer or system. This will set the statement with a clear pass or fail result that will be applicable at Epic, Feature and Story levels.
Important! Such a set of statements needs to be defined prior to the start of development as verifying the already built functionality will just give us the development reality instead of capturing the customers’ needs and focus to meet them.
- Last but not least, ask the Scrum Master to review the Sprint backlog, it is one way or another your main advisor!
5 Tips on How to Run a Sprint Planning Meeting
Wrapping up the previous, we bet you have heard a lot that planning is essential to a project’s
1. Set a Challenging Sprint Goal!
It is of great importance to set up a goal that would be specific and measurable, as a result of the discussion between the Development team and the Product Owner. It would be a piece of cake to create a goal easy to achieve that will result
2. Pre-plan the Sprint planning
Back to the process of getting organized, setting up a shorter meeting prior to the actual one is not a mandatory step, but it can be proved beneficial for the steps following. It is a chance to review the items that you intend to include at the next Sprint and listen to your team’s feedback. This way, prioritization, task creation
3. Focus on the Prioritization
There are no clear guidelines when it comes to the prioritization of tasks that will assist
4. Don’t Hesitate to Decompose your Tasks
The goal here is to avoid having any task with estimation for completion that exceeds a full day’s work. Working on a single task for two or more days will probably leave a member behind on the progress and demotivated. Breaking a bigger task into pieces can be not only an easier goal to
5. Say no to Overload!
Whilst we want the Sprint goal to be a challenge for the team, members can easily fall into the trap of getting too confident and take an insufficient load of tasks. As a result, the work to be created will be counter-productive and there is a high chance that the team will fail to deliver the expected on-time, leading in turn into irritation and disappointment to the people involved.
Bottom line to make this whole process work for your