Sprint Planning: Remember it’s a Sprint, not a Marathon
What is Sprint Planning?
Sprint planning is a time-boxed meeting that is conducted at the beginning of the sprint, where the team and the product owner discusses and decides on the work that will be completed in the sprint.
Generally, the meeting is split into two: What & How.
What?
The product owner brings a list of prioritized user stories to the meeting. Ideally, the teams’ velocity will be known and transparent so the product owner has a good idea of how much work should be able to fit in a sprint. This is discussed by the team, they break the user stories down and then agree and commit on work that can be completed in the sprint.
How?
The development team then discusses the agreed upon work, and how to go about completing it. This generally involves the team breaking the user stories down into tasks and going through the technical details. If a team practices regular backlog grooming the team should already have an idea on what the user story is about.
How it looks?
Input — Process — Output
What are the common problems?
- PO dictates and deciding what work will be completed
- The product backlog is not healthy, prioritized or ready to be discussed
- At the end of the sprint, everything is in too much detail and all work is assigned (this is hard to overcome)
- No one understands what is actually meant by done.
- The meeting is too long
- The meeting is not engaging
- Some people do not have a voice
- Poor environment and the team do not feel support or safe
- No trust or respect on both sides
- The team does not actually understand why they do this meeting
Before the Sprint Planning
Prerequisites
The sprint planning meeting is very dependent on a lot of work actually been done before the meeting. It is heavily reliant on the person that owns the backlog — the Product Owner. The PO must ensure that there is a healthy, maintained and prioritized backlog at all times. The items at the top of the backlog (which should be going into the next sprint), should be broken down and small enough for the team to discuss and plan, this is often done in backlog refinement.
A good sprint planning meeting is also very dependant on having a motivated, healthy team. There must also be a good relationship between the PO and the team, if the PO does not trust the conclusions that the team is coming to, the meeting will quickly become more of an avoidance exercise; rather than committing to what can be done. The team must see the value in doing the meeting, and see the benefits of planning this way. If there is any doubt or misunderstanding, then the process will fail.
The meeting should also be at a set time, it cannot be too long and tedious that it looses its value — and the Scrum Master must ensure that there is participation from all team members. No one should feel they are not a value to the meeting or not have the opportunity to input. At the same time, there should not be only one person doing all the work, if the PO is making all the decisions, deciding on the work and how it will be done, the team will feel it’s a waste of time and feel work should just be assigned.
There should also be a general consensus on how to estimate and break down the work, if its with story points, planning poker — the whole team should agree on a method to ensure consistency.
Make sure everyone who needs to be there is there. This should be a meeting that involves the whole team: PO, SM, developers, testers, DBA — anyone who is part of the development team should be there. Even stakeholders can attend, but should only be there in an observation capacity and not interrupt the process.
Length
The length of the meeting depends on the length of the sprint, the longer the sprint logically the more time needed to plan it. As a guideline:
- One-week sprint — 2 hours
- Two-week sprint — 4 hours
- One-month sprint — 8 hours
This is also very dependent on the maturity and efficiency of the team and the PO in these meetings, and the amount of preparation before hand. As stated, this meeting is very dependent on a good product backlog, and a good understanding of what needs to be done.
Goals
The objective of the meeting, or the outcome should be a sprint goal. What can be achieved by the end of the sprint. This is in the form of a sprint backlog; a list of prioritized tasks that the team commits will be complete by the end of the sprint. And by complete, we mean as per the teams Definition of Done. Focus on the meeting should be on the goal, what will the end of the sprint look like? If you picture the end result, refine it with the PO and agree on it — the journey will be so much easier. If the team can visually and mentally complete the sprint, it puts them in a good motivated mind-set going into actually starting the work.
One of the key principles of agile is the ability to embrace change, we know that the least about a project we know, is at the beginning. The same should apply to your sprint backlog during the course of the sprint. You start to learn more about the work and the task as you go along, so allow your sprint backlog to evolve and refine itself.
The goal is to obviously have a spring backlog at the end of the meeting, but remember its OK to re-evaluate the work throughout the sprint. Yes, you have a good plan as a result of the sprint planning, but things will happen during the sprint that are out of your control, you will learn new things about the tasks. Its perfectly OK to consistently re-evaluate the work, and reprioritise when needed.
Meeting Structure
Its good to have some structure to the meeting, a high level agenda. It does not need to be a detailed list of what will be discussed, that’s what the meeting is for — but I would advise a high level structure helps. For example: PO speaks first, team discusses the items together, Q&A with PO, sprint backlog refined, retrospective & meeting close. It should be consistent for each meeting, and will help the team to get into a good routine and get the most out of the meeting.
I mentioned it before, knowing the team’s velocity or capacity is important. Although not super accurate in regards to no two sprints are ever exactly the same — it gives good insight on what the team can deliver, including meetings, interruptions, issues, leave etc. It means you don’t go into two much detail, but at least you should discuss everyone’s schedule, who has leave and what are the available hours of the team. I’m not a big fan of detailed capacity planning, I think it’s a waste in product management. There are too many unknowns and I think it becomes too restrictive, I think its enough to take the average of the last 3 sprints velocity and use it as a guide — in end the team still needs to commit to what can be completed.
Plan for collaboration, don’t plan for resource allocation, don’t try to over optimize or micro manage everyone’s time. Plan as a team, and plan as if user stories will be worked on with multiple people. Products should be worked on as a team, and not a group of individuals working on their own tasks.
Speaking of capacity, I find its also good practice to not fill it. There will be unknown issues, problems, dependencies — it’s the nature of software development. Its good to leave some room for this and also gives the team a bit of freedom and confidence that they are not on a super restricted schedule. Its far easier to add work to a sprint (if you have a healthy backlog) than to remove from it.
Breaking Down the Tasks
The definition of done is super important in sprint planning. It means everyone knows what “done” means, its agreed upon by everyone. It removes any conflict here and gives complete transparency, so that one developer doesn’t think his task is done when the coding is finished, and the rest of the team understands its when its tested, documented and deployed. Done should mean potentially shippable.
Discuss all the tasks, user stories, bug fixing, maintenance. To get a good idea of the work involved and how it will be done, don’t forget to go through all kind of tasks; creating scripts, refactoring, merging, testing and automation, they all take time.
Don’t get too tied down into the estimating process, its an estimate, approximation — not a given or a commitment. If everyone is generally happy with the estimate and the work involved, go with it; otherwise you could end up going round in circles and wasting time. Its also important to note that no one is going to be singled out or held accountable for an estimation — there should be no fear of this in the team. No one should be comparing in detail estimates with actual time completed (unless there is a massive difference, but this should be dealt with as a team in the retrospective).
As with the above, also don’t get tied down in assigning tasks. It should be a team effort to complete the sprint goal. As long as you have a prioritized list, if one task is done your team should be looking to help others if needed; or move onto the next most important task. I have found in the past if you assign tasks, then the same people start getting assigned the same work. This is bad because then you start to develop ‘specialists’ in your team, and knowledge sharing and growth becomes restricted. Having specialists is OK, as long as they share the knowledge with the team, there is nothing worse than one person knowing and being responsible for a particular code base and then leaving — taking that knowledge with them. No one should be attached, or married to a task — as I said, it’s a team effort and tasks should be interchangeable. The whole team owns the sprint backlog, its not divided and assigned.
Try to use story points, they are a good relative way to estimate. There are a few different methods of using story points to estimate, but generally you are comparing tasks and estimating by complexity, not time. This is so much easier than giving a set time, for a developer to say “This task is 3 times more complicated than this” rather than “This task is going to take me about 4 days”. It takes some time to get used to if you do not practice it, but in end, once refined can be super effective. I would advise if you use it, stick to it. Don’t mix story points with hours, people then just start to try to convert story points to a time, then it kind of loses its value.
Consider the sizing of your tasks, and try to keep them consistent. Tasks that take up no more than one day is a logical way; it allows developers to plan their days a little easier. It also allows a little more efficiency, if a task can be started and completed in one day, its much nicer than having to carry over work to the next day. Smaller tasks give a greater vision of what needs to be done, and can also reduce bottlenecks. Don’t be afraid of going too granular, you are only planning for the duration of your sprint — the more granular the tasks the more accurate the work remaining will be. Tasks should also be as atomic as possible, so they can be worked on in parallel. Having tasks that are dependent on each other will again only cause bottlenecks and issues.
Only create tasks for the work that needs to be completed; development, testing, documentation, demo etc.… Don’t add PO work or meetings. I don’t find its worth adding these, and they will be covered in your team velocity.
If you are really unsure about a task, create a ‘spike’ task. Basically a task where you investigate, study the task and clarify any uncertainty the team has about it.
One of the things I learned early on, is to not plan for 8 hour working days. Even if your team is contracted to work 8 hours a day; they do not actually work straight 8 hours a day. Try to find out the ‘efficiency’ of your team. I generally find in a good healthy team, its about 70%, so here I was planning for 6 hour days. Not because the team didn’t work, but realization that so much happens throughout the day: meetings, lunch break, clarifications with PO, short breaks here and there.
Environment
The environment is also important. The team should feel safe, that its ok not to know everything now. Agile is all about adaption, reaction and learning. There should be a strong feeling of collaboration, support, curiosity and drive. The team should not be afraid to ask questions, to speak out. The team needs to understand as much as possible to be confident in what they can deliver and commit; and if they have any doubts or raise risks then they should be taken seriously. Its so important that the final say is with the team on what can be derived, not the PO.
I’m a massive advocator in self organizing, autonomous teams. Not because I’m lazy…. But because I have seen the results it brings. Autonomous teams are efficient because they own the product end-to-end, there is no dependencies for decision making, it promotes growth and most of all its motivating for everyone involved. As the Scrum Master you should be letting the team set their own goals, coach and mentor the team to take ownership, its their plan, its their sprint backlog. Don’t in any way hold the team back, let them surpass, surprise and innovate on their own. Let them think, its ok if the room goes quiet every now and then.
Listening is super important, especially when the PO has the floor at the start of the meeting. The team should be engaged, listening to the priorities and the explanation that the PO gives. The team should be actively listening and asking questions through this part.
I spoke about trust being important, but respect is also just as important. I mentioned that the PO should have the trust in the team, and it goes both ways. The team must respect the PO, and have trust in the decisions he is making. This is the person prioritizing their work, and they want to know what they are doing has value and is well thought out. The PO is responsible for the ‘why’, so the team should let them focus on that. The PO is responsible for stakeholder management and is there to be the voice of the business. The team is responsible for the ‘how’, its fine for the PO to listen and maybe gives some points, but in no way can they tell the team how something should be developed, its their job, they are good at it. There should be an end-to-end respect on both sides, and a clear definition of the roles each one plays.
Don’t be satisfied if the team doesn’t ask any questions, if there are no questions it implies everyone completely understands, which I think is very rare. You could have a policy in place where everyone has to ask at least one question. Usually once one question is asked, more follow.
If you are using a physical Kanban board, actually get the team to create their own post it notes, add them to the board and prioritize them, again it’s a good way to promote self organizing. Try to use the time to update your tool, whether it be a physical Kanban board, Jira, TFS during the time-box. Its good because everyone can see the plan, agree and then the work can start. Second, its good that everyone sees and understands the process. If the Scrum Master is sick for example, it shouldn’t be too difficult for a team member to stand in.
Ending the Meeting
It’s a time-boxed meeting, so end it on time. Even if the planning is not finished, its important to actually start the work, more planning will not complete the use stories. Its ok to not know all the details, it promotes agility!
So…… Just do it! The purpose is to plan and have a good understanding on what needs to be done, but I think there needs to be a line. Sometimes the team needs to have the courage to say “OK, this is enough, we don’t know everything but the rest we will learn and adapt on the way”. Part of being agile is having the ability to experiment and innovate, actually starting the work gives the team the opportunity to do this.
Reflect a little, maybe reserve some time at the end to review. Although you should have already conducted a sprint retrospective for the previous sprint; take some minutes to again reflect on what went well, what didn’t in the previous sprint and ensure that you are keeping good practices in play, and things that didn’t go well don’t happen again. It also allows one last review and OK on all the work committed.
This post was originally posted on: theproducthub.io
https://www.theproducthub.io/2019/10/19/sprint-planning-remember-its-a-sprint-not-a-marathon/
Please check my site to get the latest articles first!
About the Author
Ashley-Christian Hardy
theproducthub.io
Product Leader. Over 10 years in product development; with experience in product management, UX & UI, product design, product & delivery methodologies and product leadership. A strong advocate in innovation, experimentation and building great products with the use of qualitative and quantitative research, putting an emphasis on a customer centric design and approach.
Website: www.theproducthub.io
Twitter: www.twitter.com/achardypm
Facebook: https://www.facebook.com/theproducthubio
LinkedIn: mt.linkedin.com/in/achardypm
Medium: medium.com/@achardypm
Instagram: https://www.instagram.com/theproducthub.io/
Pinterest: pinterest.com/achardypm
SlideShare: slideshare.net/ashlychrstn
