Mastering the art of sprint planning
Sprint planning meeting is a core aspect in achieving successful Agile implementation in any organization. The art of implementing Agile and running sprint planning meetings successfully requires years of learning, experience and skills.
We contacted some of the most experienced Agile Coach, Agile Practitioners & Entrepreneurs to share their years of experience and knowledge. We wanted to find out what makes them so successful in sprint planning, Sprint tracking and implementing agile successfully in their team, organization and with clients.
What is Sprint Planning?
The Sprint Planning Meeting is the first meeting to kick off the sprint.
"In Scrum, the sprint planning meeting is attended by the product owner, ScrumMaster and the entire Scrum team. Outside stakeholders may attend by invitation of the team, although this is rare in most companies. During the sprint planning meeting, the product owner describes the highest priority features to the team. The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog." Mountain Goat Software
1. Advice for Sprint Planning
By : Kevin Brunner, Agile Coaches LinkedIn Profile
First and formost, If you are seeking any tips on sprint planning, it presumes you have a healthy team. One common source of team dysfunction starts with the person in charge of the backlog. If they aren’t sufficiently prepared for the sprint planning meeting or don’t trust the team to arrive at their own decisions, then the group behavior becomes one of avoidance rather than commitment, which defeats the purpose of going Agile.
Sprint planning when it doesn’t go well often has the following 4 complaints:
- I don’t want to spend the time and I don’t see the value in doing it.
- It takes too long and doesn’t involve me, so why do I have to be there?
- The manager does all work so in the interest of everyone’s time, why don’t they just assign the stories and finish the definitions?
- These stories are too ambiguous so I don’t know how to estimate how long it will take.
Following three tips while leading sprint planning session should ensure positive, self-reinforcing team dynamics and a clarity of vision shared amongst all the team.
1.1.1. Mentally fast forward the team to the end of sprint during the planning session.
Have them imagine all the ideal work based on guidance from the product owner, focusing on the high level picture from the perspective that the work is done and the result is delivered.
1.1.2. To get here, you can follow this script
Imagine we’re done. What does it look like?
1.1.3. How will you demonstrate it is done?
This shifts the team’s mindset from blurting out a scattered laundry list of things and towards what will be delivered and how it will be presented.
Doing this forces conversation about clarifying acceptance criteria, cutting down on ambiguity (which left unclarified can result in the wrong work being done).
1.1.4. With a fast-forwarded mindset, people are already “there.”
The journey is more effective. It’s just like visualizing victory before a race.
You’ll be surprised how good the sprint is because they’ve already finished the sprint mentally. Now they’re just going through the motions.
Foster team autonomy and backlog ownership by enabling the team and getting out of their way.
1.2.1. As a cultivator
You let the team surpass and surprise you. Don’t hold them back by controlling. It’s vital during sprint planning to communicate that it’s their sprint plan.
As a facilitator
You need to make them feel safe that they are allowed to not know everything. Your main role is less managing and more cultivating their autonomy as a team, and the key is to get them to interact with each other. You are jumpstarting and curating, not directing. It’s ok to let it become quiet. Let them figure the solution out. Challenge the team to enumerate the work needed to be done.
Encourage them to ask if they don’t know, and do so by setting an example. Let everyone be present and invested.
Set as a team the scope, time estimates, story point values or whatever you choose to call them as a team. Ask everybody to walk through their plan, so that every person can share and comment about how to support one another over the course of the sprint (it’s a good cross check). Then the group is committed to the plan because they made it.
Budget time for Retrospectives on the past sprint(s) when you’re closing a sprint and just before planning the new one.
Have you and the team been going for a while? It’s not uncommon for teams to get to a point where they believe they get no further value out of the retrospective. Don’t let that happen!
1.4. Ask the team about the previous sprint.
You can start this by asking
- What went well?
- What could use some adjustment?
- What could be done to improve future sprints?
Doing so allows the team to comment on issues before they build up into team breaking problems. It also gives team members a platform to discuss the readiness of stories going into the backlog.
If they get quiet, you can go person by person and ask “On a scale of 1 to 5, 1 being poor and 5 being just an amazing, perfect sprint, how do you think the spring went?”
This will give people a chance to say 4 out of 5 (and so forth).
Then you can continue and ask
“Well what would have made it perfect?” and this helps them to realize that they do have a suggestion to offer.
It’s a good idea to do this prior to planning so that whatever education you get as a group you can put it into practice during the planning session.
2. Three Tips for success
By : Larissa Scordato Project Manager LinkedIn profile LinkedIn profile
LaneTerralever is marketing and advertising agency have a unique take on it, since its using Agile as a agency rather then traditional sense. An Agile approach to design actually works beautifully well for LaneTerralever, since its provide the customer contric aproach. www.LaneTerralever.com
2.1. Daily scrum
A daily meeting with the team to see what's been done, what they're working on next, and if they're blocked. It's also helpful to see how they're progressing in the sprint, and helps us to stay on top of priorities throughout.
2.2. Backlog grooming
Each sprint, we have a 1-4 hour meeting (depending on the workload) to go through the backlog, and make sure we can prioritize the best things to work on for the following sprint. We also are able to add/subtract items that are new or have been descaled from the project, as well as bring up any questions we'll have for the client during sprint planning.
2.3. Building in time for collaboration
Each sprint, we bake in time for an ALL-Team collaboration meeting about halfway through, so the team members that are responsible for work during that part of the project can share their progress with everyone. This way, for example, if our UX architects create something that will take more time in development than we've scoped for, we can discuss adjustments or new items to discuss with the client.
3. Three steps to making a Sprint Planning Meeting successful
By : Tony Solomita LinkedIn profile
Of all the Scrum ceremonies, this is the one where the work done outside of the ceremony is as important as the work done during the ceremony. If Product Backlog Refinement is not done successfully prior to Sprint Planning, it is going to be a long and unproductive meeting for everyone. http://www.excella.com/
Of all the Scrum ceremonies, this is the one where the work done outside of the ceremony is as important as the work done during the ceremony. If Product Backlog Refinement is not done successfully prior to Sprint Planning, it is going to be a long and unproductive meeting for everyone.
During the first part of Sprint Planning, when the Product Owner is explaining to the team the goals for the upcoming sprint, as well as the user stories at the top of the Product Backlog, the team should be actively listening, and asking questions, throughout.
During the second part of Sprint Planning, when the team is figuring out how to build this functionality, and then estimating the work, the team should be listening to one another intently. This is a team effort and many teams get derailed later in the sprint if they don't listen to others points of view during Sprint Planning.
The Product Owner is responsible for the "why."
Let the Product Owner focus on working with business stakeholders and users to determine the "why" and then let them communicate that to the team during Sprint Planning.
The team is responsible for the "how." Technology decisions, tasking, estimates, those are all the domain of the team. Let them focus on that, they're good at it. In the end, respect what the other side is saying, let them focus on what they are accountable for and success will follow.
4. Sprint Planning Best Practices
By : Dave Todaro,President/COO LinkedIn Profile
A successful sprint planning ceremony for us actually starts beforehand, with a solid backlog grooming ceremony. Scheduled at least a few days before sprint planning, backlog grooming provides a way for the team to “preview” the top of the backlog that they’ll be estimating during sprint planning. This provides several benefits www.Ascendle.com
4.1. Tip# 1: Backlog Grooming
A successful sprint planning ceremony for us actually starts beforehand, with a solid backlog grooming ceremony. Scheduled at least a few days before sprint planning, backlog grooming provides a way for the team to “preview” the top of the backlog that they’ll be estimating during sprint planning. This provides several benefits:
- It allows the team to hear details from the product owner about the upcoming stories so they can start to understand what they’ll be tackling next.
- It lets them ask questions before sprint planning. Sometimes the product owner may not have an answer but they can figure it out before sprint planning.
- The team can break down larger stories into a more manageable, smaller stories, which makes for easier estimating.
- All this results in a huge time savings during sprint planning, since less time is spent on the team understanding “what is this” and more time is spent on breaking it down and estimating the work. It also avoids the team getting stuck because of an unclear vision from the product owner.
4.2. Tip# 2: Know Your Capacity
At the beginning of each of our sprint planning ceremonies, we briefly talk about everyone’s schedule for duration of the sprint. This uncovers things such as Bill being on vacation two days next week, and Sally being out of the office at a client meeting at the end of this week. These are factored into the typical hours available for each team member and a resulting “net capacity” is determined. This number is then used as a guideline when estimating what will fit into the sprint.
4.3. Tip# 3: Don’t Fill Capacity
Our process includes breaking down each user story into sub-tasks, each with an hour estimate. We keep track of total time and ensure the hours will fit into the team’s capacity. However, we never fill *all* the capacity. This leaves some wiggle room for unknowns that come up, including things taking longer than anticipated, a team member getting pulled onto another project for a half a day, and general “stuff that happens.”
We’ve found that it’s almost always easier to add more scope to a sprint if the team over-estimated the work to be done, versus scrambling to wrap up three user stories in the last 2 days of the sprint.
5. Sprint Ceremonies
By : Emiljana Melo LinkedIn Profile
Sprint Meeting:Creating Sprint Backlog. Task breakdown meeting: Tasks are created and sprint backlog is finalized https://www.reachpod.com/
5.1. Sprint Ceremonies
Sprint Meeting:Creating Sprint Backlog
Task breakdown meeting: Tasks are created and sprint backlog is finalized
Sprint is reviewed and tasks are prioritized
5.3. Blocking Grooming
The product owner and the team reviews and fills gaps on the product backlog
5.4. Sprint Retrospective
The process is evaluated
5.5. Sprint Velocity-How much should be accomplished on each sprint
Agile allows team members to communicate and collaborate, which produce self-directed agile development.
6. Successful sprint planning and Achieving the Sprint Goal
By : Damon Poole, Chief Agilist LinkedIn Profile
When an iteration is long, there is more room for waste to be created ‘just because.’ http://www.eliassen.com/
Here are his three tips for successful sprint planning and achieving the “sprint goal”
“Tip No. 1 – All ‘sprints’ should be kept short
A sprint, also known as an iteration, should be 1-4 weeks in length. The iteration length puts a lot of stress on the team to keep the amount of documentation to just the necessary minimum to meet the needs for collaboration and tractability for regulatory compliance. When an iteration is long, there is more room for waste to be created ‘just because.’
“Tip No. 2 – Keep the length of your ‘sprints’ consistent.
Unless you are considering a long-term change of cadence, the iteration length, once chosen, should remain stable. This is the only way that planning can become accurate. Mess with the iteration length, mess with the release estimate. Changing things up also undermines the trust relationship between the product development team and the business. Trust is one of the most important things within business. Without it, communication suffers and then quality and estimation suffers.
“Tip No. 3 – Done means Done.
At the end of the sprint, the work done within the iteration must be shippable. It is tempting to have a nonchalant attitude regarding the requirement that each iteration be “shippable.” One of the most common anti-patterns of iterations is to treat them as milestones. A milestone is just a date by which you hope to show evidence of progress on an agreed list of goals. Evidence is not proof. Iterations require proof. You need to prove that at the end of the iteration you could push a button and that new functionality would be usable by real users and that you would feel just as comfortable pushing the button at the end of the iteration as you would at the end of your current release process. Of course, it takes time to achieve this goal, but that is the goal. For every iteration that is short of that, you should be thinking of what you can do with the next iteration to get closer to that goal.”
7. Sprint Ceremonies
By : Trevor EwenSenior Software Engineer LinkedIn Profile
The worst part of scrum is the environments that mislabel “modified” waterfall methodology as agile. http://www.neosavvy.com/
7.1. Just Do It!
The worst part of scrum and agile methodology is to experience the environments that mislabel modified waterfall methodology as agile. There are teams who feel that if they have a morning meeting, they are suddenly practicing agile. All the pieces are necessary: The frequent releases, the MVP methodology, the grooming of the agile board, sprint planning, retrospective, morning standup, everything.
7.2. Curate and groom the backlog, regularly
A stale ore misrepresented backlog will create a lack of confidence in the teammates. People will start assuming what tasks they are supposed to do, instead of knowing. It's typically thankless work, but someone has to be in charge of making sure things stay up to date.
7.3. Empower all team members to enter their own tasks/bugs
As a member of a technical team, you can very easily feel overwhelmed. Sometimes there is too much work. There is amazing freedom in using a scrum/agile board to relieve that pressure. You will be able to instantaneously take weight off your shoulders and shift it amongst your teammates. People who are especially good with delegation will likely be more useful in future sprint planning.
Running sprint planning meetings and implementing Agile Methodology in any project doesn’t have to be a rocket science. Moreover is just a common sense, which require some experience, I am sure you must have using some of the tips from above, if you still struggling to get a good grip in your agile project, the above tips and advice come handy.
How can we more successful in Agile Methodology?
Share your magical agile tips or experience, which other can be benefited with