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.
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 an AgileAlliance.org.
Great list here. Simple and to the point!
Imho as much acceptance criteria as possible should be added to a user story befor doing the estimation. Because acceptance criteria help to get a better picture of the story and therefor help to make estimation easier/ better.
Christian – thanks I’ve thought about this a bit before and I’m ambivalent. Sometimes they’re discovered before Backlog Grooming and other times they’re not. I don’t general find their absence to make a big difference with estimation. It often happens that team members ask clarifying questions while doing the estimation that help discover the boundaries and so the acceptance criteria. I do expect them to be in place for Sprint Planning.
Cheers
Mark
Sure, they can be added at (nearly) every point in time, as they are “discovered”, but it doesn´t hurt to have as much as possible as early as possible. 😉
I’m with Christian regarding the need for getting acceptance criteria at the time of estimation. Without acceptance criteria you run the risk of hearing things like, “No, that part is a separate story, didn’t we say that during estimation?” or “Did we include that for this estimate?”
Also, I’m a bit surprised by the “who” in your table for acceptance criteria. I’ve always worked with the goal that acceptance criteria comes from the team during story grooming. Doing this helps create dialog, especially in environments where team members are used to just following specs. (Think “conversation” from Ron Jeffries three C’s)
Ok I could have stated it better. Acceptance criteria can come from anyone on the team. However I find they most of come the PO and QA.
As to when: sometimes they’re discovered as part of estimation and sometimes not.
However I wrote this item to clear up some large scale mis-conceptions (i.e. Backlog grooming what’s that), I realize there won’t be full agreement on some of the fine details.
“Not a meeting, just something that happens on an ongoing basis”
The only kinda of planning worth it’s weight.
Where is the planning of considering one product enhancement over a different one?
Where is the planning for the timeframe of delivery?
Alan – thanks for taking the time to comment. Remember this was just meant to be a basic outline.
Considering one product enhancement over another isn’t so much a planning problem so much as a prioritization problem. As a result I just didn’t cover it here. Use any technique you want Lean Startup, … .
Planning the time for delivery is that what I called Release Planning Part II?
Cheers
Mark