What is a sprint planning meeting?
Planning sprint is one of SCRUM’s five events that previously used to be described as ceremonies.
The start of the planning sprint marks the beginning of the sprint and the purpose of sprint planning is “to perform with an aim of doing things quickly and effeciently”. Sprints are like short bursts of speed in an SDLC and non SDLC environment, where sometimes, an MVP needs to be pushed out as soon as possible.
“This plan is created by the collaborative effort of the entire SCRUM team at Productivity Land!”
Few of the key inputs to a typical Sprint meeting are the product backlog, the latest product increment, the project capacity of the development team during the sprint, and the past performance of the development team.
A product backlog in scrum comes with a certain amount of assumptions. The assumptions include: the items are ordered, prioritized and at least estimated.
Long story short, the Scrum Master calls the meeting and the development team and product owner are part of the meeting.
In an ideal scenario, the development team collects high priority items from the product backlog. It’s important to know that they may or may not select the items which are at top of the item list.
Part of the art of scrum is selecting items that are coherent; the kind of items that make sense if they are developed together. So far it looks like this planning sprint meeting is boring for the product owner… The reality is quite the opposite of boring.
One of the Main Issues of Sprint Retrospective Meetings:
The main issue with Spring Meetings is any number of people not showing up! Yeah, this happens a lot. When you are dealing with a handful of team memebers, they are all not very punctual at times. Some memebers show up early, others show up late.
As a result, the late memebers ask the project manager to highlight the minutes of the meeting. This hectic activity results in wasting more time, instead of resulting in productivity. These issues are common. Given that Sprint Meetings span over 15 minutes, tops, it becomes a hassle to keep everyone on board…
Moving On:
The product owner can help to clarify the selected backlog items and make trade-offs.
I mentioned earlier this notion of selecting coherent items and this ties nicely with the SCRUM Goal.
During the sprint planning, the scrum team also crafts a sprint goal.
The sprint goal is the objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the development team on why it is building the increment.
Excellent… We have our Sprint Goal and we have our selected Items which is our Sprint Backlog… Or do we? We’re only halfway there…
So, we selected some items from the product backlog, and we established the sprint goal and in any sprint planning session that I have been involved in that has been the end of the story. The team will be headed to the nearest coffee machine.
But… I have not hit the bull’s eye yet…
Planning Sprint has not one but two parts to it.
Topic One: What can be done in this Sprint?
Topic Two: How to go on aout getting things done?
Having selected the sprint goal and selected the Product Backlog items for the Sprint, the development team decides how it will build this functionality into a “Done” product Increment during the Sprint.
And standby for another surprise… The product backlog items selected for this Sprint and the plan for delivering them is called a Sprint Backlog.
Did you get that? As it turns out the Sprint Backlog is more than a selected subset of the product backlog. It’s that subset plus a plan for how that sub-set will be delivered.
So not only just the What but also the How?
Clearly, I’ve been getting this wrong for a very long time. For you is Sprint Planning just a process of selection or do you create an all-important plan?
Before we head forward to the next section; to hold an effective sprint planning meeting you’ll need to cover the following prerequisites:
- Prioritize User Stories and Product Backlog
- Planned Capacity of the Team
- Definition of Done
In addition, you need to know what Planning Sprint Time Box is all about. For a one month or four weeks sprint, this meeting should last eight hours. For a two-week sprint, plan for about four hours. As a rule of thumb, multiply the number of weeks in your sprint by two hours to get your total planning sprint meeting length.
Merits of Planning a Sprint:
Now the main benefit of a planning a Sprint is performance visibility. This allows a team to begin a new task with what they will work on for that sprint & it serves as an initial plan on how they are going to approach that work.
Apart from this, there are many additional merits:
- Scope Visibility
- Task Discovery
- Optimal Usage of Capacity
- Improvement in Team Collaboration
- Controlled Scope Creep (continuous uncontrolled growth of the scope)
Now planning a sprint can become highly ineffective if your team does not have a well-redefined product backlog from which you have to draw product backlog items.
This can be looked into by creating a continuous product backlog process that results in a set of product backlog items that meet and agree to the definition of done.
Then these product backlog items can then serve as the potential items which be included in the sprint. Another common obstacle when you don’t establish a specific goal of the sprint and you end up with a set of unrelated items that everyone must work on.
How a Planning Sprint Meeting can be Made Easy?
Let’s talk about prerequisites. To do a sprint planning meeting; you need to have the following things:
- Prioritized Backlog
- Groomed & Estimated User Story
- Definition of Ready
- Planned Capacity
Product Prioritization Backlog: In Agile software development if we have a list of product backlog items to find out which product or feature, we need to work on first and deliver.
There are mainly two main benefits of product prioritization backlog; one is the business benefit and the other is the benefit to the development team. Additional benefits include customer satisfaction, better management of dependencies, managing risk and keeping the focus on value-based development.
If you have your backlog set in order, then it will be very easy for the development team to identify which story to groom first. That saves time for the scrum master, product owner, and the development team.
If you have more bandwidth and during your sprint, you need to pick a story you can take a quick decision as to which story to pick. Because all your stories are stacked in a prioritized way. Otherwise, you can always identify and drop a story if you require it to prioritize.
Groomed & Estimated User Story: Story points are a unit of measure for expressing the overall effort that will be required to fully implement a product backlog item or any other piece of work.
When we estimate a story point, we assign a point value to each point. The raw values we appoint have little value. What’s important is the relative values we assign. A story is assigned a two, should be twice as important as a story assigned a one.
Instead of assigning a 1,2,3 the teams can assign 100, 200 or 300. It’s not the number that matters but the ratios that matter.
Story points represent the effort that will go into a story. That could include the amount of work to do, the complexity of the work and the risk of the work being planned.
Definition of “Ready”: The definition of ready is a documented team agreement that defines the condition which must be met for a product backlog item to be ready to be worked upon by the team.
It’s not a formal contract but a set of guidelines for your team to make a decision and trade-off to getting started.
Creating or following the definition of ready can easily speed up team speed by twice as much.
For a real-life example, “Everything is in its place in a cooking show”. Before they begin preparing the recipe, they carefully organize and measure the various ingredients because they are clearly available for use.
Planned Capacity: Planning the capacity means to estimate and calculate the capacity or available productive bandwidth of a Scrum Team.
During the Sprint Planning Meeting…
What is the longest possible allowable iteration, or Sprint in Scrum? Well as per the basic guidelines, it’s 30 days or less than one calendar month.
Traditionally, when I’m executing a Sprint, I keep it at 2-weeks’ distance from one meeting to another. Scrum teams plan to build a potentially shippable product increment every Sprint.
This requires every sprint to possess a mixture of study, design, implementation, testing, integration and deployment. At this point, you may have a question – i.e. How will we get that done within two weeks? Well, as it turns out, during backlog refinement we normally divide the original epics into smaller user stories, representing thin vertical slices.
We’ll still have to work as a sprint more than a traditional team. That’s why we’ve got a team room. 
Remember it’s the responsibility of the Scrum Master to prevent any other people from interrupting you with unrelated work.
If anyone asks anything unrelated to our Sprint Goals, send them to the Product Owner so that we can add it to our Product Backlog.
The Product Owner won’t interrupt the Sprint unless it’s an emergency.
7 Essential Measures you can take to Improve Program Management
So now before we commence any further, I’ll share how can one Scrum Team build a potentially shippable product increment within one Sprint? By agreeing to a smaller amount of feature scope at the Sprint Planning Meeting, allowing longer for integration, testing and fixing during each Sprint. You need to keep an eye out for other variable factors, such as but not limited to:
- Using modern software engineering approaches like test-driven development (TDD), continuous design, continuous integration, merciless refactoring.
- Improved collaboration techniques, pair programming, working during a team room and eliminating “over the wall” handoffs.
- Full-time allocation to at least one team, that specializes in just one set of Sprint Goals.
- Checking code in multiple times per day, and by reducing or eliminating branches within the version system
A common question that I get asked is that a 30-day Sprint uses a 1-day timebox for the Sprint Planning Meeting. How long should the Sprint Planning Meeting be for the two-week Sprint? My recommendation is for 4 hours.
So, what should be our goals for a Sprint?
The Product Owner might respond that during this sprint I’d be happy to see some rudimentary capabilities with grading. Subsequently, the development team will discuss that this is the Product Owners top priority item. Do the rest of the development team thinks that we could do this in our two-week sprint?
After the development team has accepted that it is possible, the next step is determining what is our definition of Done?
To avoid technical debt, what should the team write down in their definition of done? A couple of definitions which I’ve listed for your consumption are:
Regression tests for a brand spanking new functionality run automatically with every build
Code has been written by pairs or at least reviewed by other members
Summarizing also needs to account for the following factors:
- Properly Tested
- Refactored
- Potentially Shippable
The product owner might believe that he can work with something simple that works properly. The complexity can be folded in later. The Scrum Master will subsequently need to agree with the Product Owner and the Development Team whether PBI will need some testing tasks?
Sometimes development teams feel test-driven development skills aren’t that good yet. This will take a bit longer than our way of working. Yes, initially it might feel like it’s going slower. If you commit as a team using Agile Engineering practices consistently, you’ll eventually be faster from a business perspective.
Using craftsmanship to create innovative products isn’t about how briskly you type code.
The scrum master will then need to identify what other tasks are missing to get this into a potentially shippable state?
During this process, normally development team members think we can do this in two weeks, without compromising our definition of done and without working overtime?
So who is responsible for committing to work in the Sprint Planning Meeting? Yes, it’s the Team.
A lean principle behind Scrum is to limit add Progress (WIP). Humans don’t multitask efficiently. Too much add progress actually slows things down.
SO by now, there are a lot of tasks lined up. Should we decide which individuals are doing which task now?
In the Sprint Retrospective Meeting, we decided that team members should wait until the last responsible moment to volunteer for tasks.
Now let’s wrap up whatever we have learned about Sprints:
How many sprints are planned during a Sprint planning meeting?
One sprint only. Once the team has established a uniform velocity, the merchandise Owner can use this velocity to form longer-range forecasts and release plans.
Who ahould attend the Sprint Planning Meeting?
- The Product Owner
- The Scrum Development Team
- The Scrum Master
What does a Scrum Team attempt to do during its very first Sprint?
Analyze, design, build, integrate, and test potentially shippable product increment, even its features are initially simple and little.
Which of the following are true regarding Backlog Items and tasks?
- A PBI is more about what than the HOW. A task is more about How
- A well informed PBI represents distinct business value, ideally from the customer’s perspective. A task is simply a step by the team to make that value.
- A task should be no bigger than at some point of labor
- Some scrum teams who have learned the way to define sufficiently small PBIs not find tasks necessary.
- The product backlog should contain well-informed PBIs and not tasks.
Conclusion:
By now, I hope you gathered some knowledge and information about the basics of Agile Spring Meetings. Having said that, this post is still non-conclusive because a lot of things were not discussed in it. Do bookmark this page, and revisit after a week or two for additional updates.
In case you have anything to add, based on your previous experiences as a project manager in any industry, feel free to use the comments section below.
The post How to Run a Sprint Planning Meeting like an Expert? appeared first on Productivity Land .