Set Your Agile Project Up for Success
Your department is busy, and as hard as it can be to make the time, it’s in those moments that it is good to get back-to-basics, setting your agile project up to succeed. Whether you’re new to agile techniques or well acquainted with your scrum team, effective sprint planning is the difference between smooth, steady, purpose-driven development and a project that quickly drifts out of scope.
As you read this, and as you plan your next few sprints, you may want to follow along the Sprint Planning Checklist.
Your Sprint Planning Meeting
It doesn’t matter if it’s your team’s first sprint, or 100th sprint, sprint planning is a new beginning. With a product vision clearly defined and an updated product backlog outlining how your scrum team plans to achieve the vision, sprint planning is the opportunity to mobilize the team around the next highest priority set of functionality to develop fully and demonstrate to stakeholders at the end of the sprint. Your product owner, development team and scrum master take the time to:
- establish and commit to a clear sprint goal that aligns with the release goal and product vision
- adjust ground rules (e.g. working agreement) and the definition of done–what it means for the new functionality to be “potentially shippable” at the end of the sprint–as needed,
- identify product backlog items needed to accomplish the sprint goal (this includes creating new ones if they’re missing)
- confirm capacity of the development team for the sprint to ensure the sprint isn’t overloaded with scope and the scrum team can continue to work at a sustainable pace
- create the sprint backlog by breaking down selected product backlog items into the tasks required to develop working, shippable functionality that meets your definition of done, as well as each product backlog item’s acceptance criteria
- visualize the sprint backlog, which may include other progress indicators like a sprint burndown chart, not only for the scrum team but also for stakeholders
Up until sprint planning, the scrum team has been progressively elaborating the product backlog. It should not be the first time the developers and product owner have discussed the product backlog items being considered for the sprint. Product scope has been flexible all along, but at sprint planning the scrum team needs to lock down a portion of scope so the development team can implement something tangible. With this contextual background already under their belts, they will have further discussion to make sure each product backlog item’s acceptance criteria is clearly understood to execute effectively. It’s about setting realistic goals that build a valuable product increment each sprint. This means the development team takes the time to detail tasks that will be delivered and establish what success looks like for each of those tasks.
Setting Your Sprint Goal
Your team is together and you’ve covered the basic introductory details – it’s time to dive into goal setting. The temptation may be to let the tail wag the dog by selecting “shiny object” product backlog items without considering an overarching objective or goal that is in alignment with the release goal and product vision. Don’t start sprint planning by skimming through the product backlog and throwing a bunch of ideas at the wall to see what sticks or fits capacity. Some stakeholders will have loud voices. There will be competing priorities. The product owner’s difficult but vital job is to consider all stakeholder feedback, collaborate with the development team on feasibility, and then make a purpose-driven decision on what the sprint goal is. Only after this direction is established, then select the functionality requirements to achieve that goal.
This is a crucial step for incrementally achieving your product vision through demonstration of value each sprint in your project. Without defining the value of what can be done and what success looks like for your team, you risk your team losing momentum from the overwhelming sense that things are never really done.
What tools do you have for establishing strategic direction each sprint? The first step here is to stop and review the overall situation as a scrum team. This may be in the form of the product vision statement, the product roadmap, a release plan, or even a user story map. This may be something completely different too; no matter how your situation is laid out, talk it through with your team to:
- Develop a common understanding of where you are in the process
- Define what is the needed next step on that path
- Develop a common understanding of the lift required for this step
Priority Setting to Support Your Sprint Goal
As a scrum team, you’re committing to accomplishing the sprint goal. How the scrum team accomplishes that sprint goal is fluid throughout the sprint. In reality, not all sprint backlog items will always be completed in a sprint. That’s just normal. This is why it is so important to identify the product backlog items that support the sprint goal, and prioritize them within the sprint. Priority may be determined by business value, complexity (important to do earlier than later, when you have the longest runway remaining), level of effort, or other factors. Since each piece of functionality will be built and fully baked before starting on the next piece of functionality, if not all functionality is completed within the sprint, it shouldn’t matter. Skeletally, the scrum team should be able to accomplish the sprint goal with 70-80% of the higher priority sprint backlog items. Lower priority items in the sprint may be nice to have, but shouldn’t be necessary to achieve success for demonstrating a valuable, shippable product increment to stakeholders.
If a sprint goal requires such a large amount of scope to complete in order to demonstrate any value, then it’s possible the sprint goal is too broad, vague or large and should be broken down. If you can’t deliver a little in a month or less, you can’t deliver a lot.
How do you know how much your scrum team can accomplish in a sprint? Well, for sprint 1, you have to take a guess. However, after sprint 1, you no longer need to guess. Since the developers will do the same type of work every sprint, getting one feature developed to a done state at a time, the amount of work they are able to accomplish in one sprint is a significant indicator of what they’ll be able to accomplish in future sprints. Velocity, which is simply a post sprint measurement of a scrum team’s output, can be used empirically to forecast the next sprint. It’s okay for scrum teams to stretch themselves, but keep past performance in mind: this is an ever growing process to help your team accomplish goals more sustainably without being pushed to the point of breaking.
Building the Backlog for Your Sprint
With a clear sprint goal and product backlog items chosen to support the sprint goal, it’s time to create and review the tasks that will bring the sprint goal to fruition. As the development team does this, be sure the scrum master is helping them ask questions such as:
- Are there known conflicts?
- Are there areas that are unclear? (If so, how do we rectify that?)
- Have we defined success for each task?
- What is the tactical approach for each of the tasks? (Do all affected parties understand it?)
- Have all dependencies involved in these tasks been broken down?
- Are the tasks broken down to be accomplished in a day or less?
- Now that you’ve built out these tasks, is the sprint goal still attainable?
Use this checklist to help you consider these and other factors during sprint planning. The sprint backlog you create during sprint planning will be your guide as you proceed throughout the sprint; take the time now to ensure each factor is accounted for.
Verifying and Committing to a Sprint
Your scrum team has their data and a plan! Before finalizing sprint planning, most scrum teams will review the planned work and compare it against their capacity. Velocity is one input to projecting capacity. Time off and other schedule issues should play in, as well. Whereas product backlog items may be estimated using a long-range relative estimation technique (not a measure of time), tasks are usually estimated in hours, since they should be accomplishable in a day or less.
How do you know if you’ve overplanned? Don’t plan every hour available in the sprint. It’s wise to leave some slack–around 10%, depending on the maturity of the scrum team. If the scrum team is new to scrum and/or to each other, 10% of slack may not be enough.
Time to verify all parties understand what success looks like, and that capacity is planned appropriately for the sprint. At this point, you want to make sure that the entire team is set up to be not only efficient (i.e. working fast) but also effective (i.e. working on the right things) throughout the process. Be sure you’re all in alignment with the goals and the tasks.
The last thing to do in sprint planning is have each development team member select the first task they’re going to work on. (Don’t have them select all the tasks they’re going to work on throughout the sprint–only the first one. As they complete their first task, they’ll pull the next highest priority task.)
Ready, Set, Go!
Congratulations, your sprint planning has occurred and your team has gone off to focus on their work. Here are a few things to keep in mind as you progress through your sprint:
- Keep the scrum team’s definition of done visible at all times in their work area.
- The sprint backlog is the scrum team’s progress reporting mechanism. There should be no need for status reporting meetings outside of this.
- The daily scrum is not a status reporting meeting. It’s a coordination meeting–a miniature planning meeting to synchronize the work to be done for the day in order to get closer to accomplishing the sprint goal.
Follow the guidelines above to improve your team’s agile approach to product development. Don’t worry if you don’t have it all down the first time. Each sprint will get better as you inspect and adapt all along the way. Let us know if you’re ready to take your professional project management skills to the next level. There are classes near you.
