Sprint Planning is one of the 5 events in Scrum.The duration or length of this event is anything between 2-4 hrs, across a 2 week period. This is a recurring event that happens on the first day of every sprint.This blog captures some pointers that all participants must bear in mind to plan effectively on the work items to be taken by the dev team for the upcoming sprint. Collaboration ,participation, content readiness are key elements for effective planning. Before getting into the checklist of tasks / items that have to be in place and the 9 pointers for making the experience of planning smoother and effective lets see the participants who are to be present in this ceremony. Listed below are mandatory stakeholders.
- Product owner: sets sprint goal, provide functional clarity, prioritize and order sprint backlog
- Scrum Master: facilitates, probes the Dev team ,checks to see if the sprint plan is realistic and achievable
- Dev team: plans the work items
- Tech leads: provide tectonically clarity
The triple constraints or the Iron Triangle in Scrum are of paramount importance in planning – namely time, cost. The Time (Sprint Length/ duration) and Cost ( Resources) parameters are fixed, while the Scope (User stories) can be flexible. Prioritizing and descoping of user stories in a product or sprint backlog resting with a Product owner.
Below is a list of items / tasks to be completed before planning a sprint – commonly referred to as the Definition of Ready (DOR). A sprint’s DOR must be thoroughly checked, with all items marked as prerequisites in place. Below listed are the usual elements that make up a DOR
- Backlog Refinement in the previous sprint should have given rise to the Sprint Backlog of the forthcoming sprint.
- Formulate Sprint goal which is nothing but the outcomes expected out of a sprint.
- Check all user stories populated in the sprint backlog are technically feasible and aligned with the sprint goal
- All the user stories should have acceptance criteria , wireframes and other relevant information
- Populate the sprint backlog with estimated and ordered user stories
- All dependencies between teams or user stories should be sorted and risks mitigated
- Calculate the teams historical average velocity and keep it handy<
Once these prerequisites are in place, below are next steps or activities to be conducted, We call them the 9 steps for effective sprint planning :
1) Discuss every user story in the Sprint Backlog to remove any doubts around functionality or technicalities ( Dev Team)
- Backlog refinement should be used by Dev teams to understand user stories in the previous sprint
- Sprint planning should be used as the last opportunity for dev teams to gain technical and functional understanding – before committing to stories
- QA and Developers should proactively discuss every user story and its acceptance criteria.
2) Re-estimate or estimate the user stories wherever needed ( By Dev Team)
- Dev team should re estimate user stories if needed after seeking clarity
- Once the sprint starts the user stories shouldn’t be estimated
- Everytime a user story is discussed the team gets a clearer picture on the requirements thus making it either complex or simpler than before
3) Break down a user stories into technical tasks needed for implementation (By Dev team)
- Dev teams should identify activities or tasks required to build the story; for effective estimation
- Ideally tasks should be broken down to a level where each of them can be completed in a day’s time by an individual. By having a discussion around tasks needed to build the story, risks and issues can be uncovered
- Tasks shouldn’t be generic eg: Implement the code, build the design, test the story, These should be technical in nature
4) Create spikes or technical tasks wherever a user story exhibits some level of risk or complexity
- Dev teams should break complex user stories (or those with many unknowns) into two parts – a task and a story
- The task or spike helps explore the story to uncover unknowns and must be taken up before the user story
- The spike story/ task should also estimated
5) Assign the work items/user stories to yourself based on capacity and capability (By Dev team)
- Product owner decides the requirement or a sprint goal
- The autonomy to choose the user story for implementation is given to the Dev team
- Based on the capacity in the sprint and their tech capabilities the dev team members choose the user stories
6) Conduct a vote of confidence review (Dev team)
- Dev team must plan the sprint backlog based on the average velocity and their capacity
- The stories are to be clearly defined, estimated and assigned, team members may vote on the scale of 1-5 (Highest) on how confident they are in meeting the sprint goals
- If the team exhibits low confidence, Product owner and tech leads must revisit the user stories to help the Dev team in gaining clarity
7) Set objectives for the sprint based on the outcomes needed (Product Owner)
- Sprint goal captures the high level summary of what needs to be accomplished during the sprint duration. This goal is reflected in the sprint backlog in the form of user stories. Product owner sets the initial goal during refinement.
- Based on the teams inputs on whether it is possible to achieve the goal given the capacity and average velocity the sprint goal may be refined during sprint planning
8) Estimate the user stories in story points and commit based on average velocity of the team
- Team velocity is calculated in story points
- Figure out how many story points of work should be taken by the Dev team during iteration
- Consider average velocity for the last 3 or 4 sprints or in some cases last sprint’s velocity.
- Identify if the upcoming sprint is different from the previous sprints in terms of number of team members, holidays, planned leave etc. Based on this capacity must be adjusted
9) Commence the sprint and announce the start of execution
- Ensure the stories are estimated in story points, assigned and arranged in the order of priority in the backlog.
- The highest priority items stay on top of the sprint backlog. Once the team commits to the sprint goals, the sprint must be started.
At the end of sprint planning the Dev team gives commitment to the sprint goal.
Hope you found this blog informative!
We would love to hear your feedback on the above best practices. Please reach out to us at “consult@benzne.com” for further details on these steps or for any support in your agile transformation journey.
Sudha Madhuri
Benzne Agile Consultant
