Basic Explanation of the Different Parts of Agile Planning
Agile Planning has many distinct phases and when you’re first learning it’s hard to keep track. This table is an attempt to simplify some of that. Note that release planning is split into two parts to make them distinct in practice. They’re normally just part of the same meeting, run on successive days.
For the sake of simplicity, I’m ignoring anything beyond release planning (e.g. strategic, roadmap, …), but you should definitely have some.
Layers of Agile Planning
| Activity | Purpose | Attendees | When | What Happens |
|---|---|---|---|---|
| Initial Product Backlog Refinement | - Establish a common Vision - Create initial Product Backlog - Prioritize - Estimate | Whole team + Stakeholders (where possible) | At the Team Launch or before starting work on a new release | - Vision - The Product Owner presents their business case/problem, preliminary sketches, and any other information that would help the team understand the business needs. The PO and Development Team collaborate to express this as a Vision. - Initial Product Backlog - The team works in small groups writing User Stories to meet the Product Owner’s needs. - Prioritize – PO prioritizes the Product Backlog with input from Stakeholders and team. - Estimate - Using Planning Poker, the team estimates the size of the User Stories in story points. |
| Ongoing Backlog Refinement | - Refill the Product Backlog - Ensure team members have a common understanding of Backlog Items | Product Owner working with other team members + Stakeholders (where possible) | Not a meeting, just something that happens on an ongoing basis | As the team completes existing User Stories, the Product Owner works to restock the Backlog with new Stories. Often these Stories come from breaking down Epics. The intention is to maintain a list of Stories sufficient for the next 3-4 cycles of work (~30-40 Stories), anything beyond should be left at larger chunk sizes. Estimate new/changed Stories both to understand their size and also to ensure team members have a common understanding about what the work represents. |
| Write Acceptance Criteria (Part of Refinement) | Clarify the details behind a Story | The people who will do the work (e.g. BA, Dev, QA, …) in concert with the Product Owner | Not a meeting, just something that happens on an ongoing basis | The Product Owner writes a series of statements that make it clear to the team what is and isn’t included in a Story. These are typically very short and could fit on the back of an index card. |
| Sprint Planning | Commit to Stories for the next Sprint | Whole Team | At the start of the Sprint | The team uses their velocity in Story Points to determine how much work they can commit to. They break the Stories down into tasks. Estimation in hours is done only to ensure that the team is on the same page and hasn’t over-committed. Many teams eliminate Estimation in hours as they mature. |
| Daily Scrum | Prepare for collaborating for the day, plan for what will happen today | Whole team | Daily, preferably as early in the day as possible | The team check what work they completed yesterday, recheck what they can complete today, and share anything that is slowing their work down. |
Mark Levison
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org and AgileAlliance.org.
