Scrum Master's checklist during Planning
The scrum guide can be vague and brief, hence a new Scrum Master will need more specific steps to follow.
For that reason, today I would like to give some directions for those in need of clarity.
What is the outcome of Planning
Any discussion becomes more focused and effective when the expected result is clear. For Planning ceremony, the outcome is to build Sprint Backlog, which is the team's commitment for the upcoming sprint.
Planning Activities
1. OPENING
Define a Sprint goal
A team should have a goal for the next sprint. That helps with better planning and defining the priorities. An example could be to finish all the leftover items related to a specific feature, or no critical bugs for a currently releasing product.
The point is that every sprint is a new start, so it’s important that PO and the team agree on the purpose of the given sprint, which helps with fewer surprises at the end.
Review vacation/days off
Team’s velocity can be greatly affected by such factors as the team’s training, seminars, public holidays, vacations, etc. Hence, it’s essential to confirm the team's capacity before any kind of discussion. That should help manage risks of not meeting the sprint's commitments.
Check for incomplete items
Before assigning any new stories, look for any unfinished work from the previous sprint. Such items will affect the team’s capacity, so do it before taking any new tickets.
Usually, there are 2 cases:
a) Partially worked-on items:
If you plan to work on those items in the nearest future, it's preferred to carry them over and complete. Otherwise, the team may spend more time to recall/investigate what's already been done than to finish the task in the first place.
b) Items still not started:
Depending on their priority, they can be moved back to Product Backlog or carried over.
Confirm velocity
Assuming you know your team’s average velocity, it’s always better to check whether the points described above would make an impact.
2. DURING
Go through the prioritized list of items one by one and put them into the sprint till the team’s capacity is full
Product backlog should be prioritized ahead of the planning. Knowing the size of the high priority items can help further adjust their order if needed. Ideally, PO is always present to answer the team’s questions, but if it’s not the case, having a priority list is an absolute must.
Questions to ask:
- Are description and acceptance criteria clear? The purpose is to clarify all the questions on what and how the work will be done. This is the time when you check whether planned stories are ready to be taken into the sprint. Size the stories or confirm the points if already assigned. Create additional subtasks if needed.
- Who can work on it? Even though Scrum Guide suggests to commit stories per team rather than per each team member, I am suggesting to check whether the needed skill is present (maybe a front-end developer is on vacation?).
Never assume that the team will be working 100% of their capacity. There are meetings, clarifications, bugs, etc. It’s always good to leave some buffer (20-40%) to be on the safe side. I believe under-commitment and over-delivery are better than not meeting commitments at the end. You want to see happy customers and a healthy team 😉.
3. CLOSING
Review the work spread across the team
Before closing the ceremony, make sure the work is split in the most effective and optimized way to deliver the most value as quickly as possible.
An example could be having similar or dependent items assigned to the same developer to avoid the overhead of blocking each other.
Who should attend
- Team: to plan and commit to their work for the next sprint.
- PO: to clarify questions, if any.
- SME, Stakeholders (optional): to answer additional questions outside of PO’s awareness or in case of PO’s absence.
How long
Scrum guide recommends eight hours for 1-month iteration. The shorter the sprint's length, the shorter the Planning should be. When agreeing on the sprint's length, consider such factors as the size of the team, collocation, readiness of the stories, etc.
The main point is to use just enough time to have a focused conversation and agree on the Sprint Backlog as a result.
How often/when
Planning should happen once per sprint. It can happen at the beginning of a new sprint or at the end of the old one. The only condition is to do it after Review and Retrospective ceremonies as their output can affect the plans for the next sprints.
Here are some examples of how the other ceremonies can affect Planning:
1. During Retrospective, the team mentions problems with the testing environment, which causes lots of delays when writing automation scripts. During the discussion, it becomes obvious that it's better to fix this issue asap. As a result, plans for the upcoming sprint change.
2. During Review, stakeholders are not happy with the shown features. For this reason, some work that has to be redone gets prioritized over already planned items. There is an upcoming meeting with investors, so no one wants to risk those relationships.
Happy Planning, everyone! 😉
If you need some tips for other ceremonies, check my other articles What's the point in Daily Scrums? and How to make retrospectives better?
Comments
Post a Comment