Agile practices, and scrum in particular are really strong at prescribing steps to go from sprint start to end. Teams practicing scrum will usually have a commitment meeting at the start of the sprint to decide the scope of work they aim to complete and daily standups during the sprint to discuss status and blocks. At the end of the sprint there should be a demo for product owners and stakeholders. Most teams also do a team retrospective to discuss what worked during the sprint and to identify process improvements.
Teams adopt different release management practices to go from sprints to releases. Organizations that have implemented continuous integration and continuous delivery pipelines and other devops practices often look to release frequently, while others that require more end user communication or training look to normalize a release schedule of major and minor releases.
Agile practices to plan and write stories
But where’s the process rigor in getting stories written, reviewed, solutioned, and estimated? If your product owner or a business analyst is writing stories, when do they need to have stories completed so that teams are ready to execute on them?
In my book, Driving Digital, I detail an agile planning process that’s prescriptive on how and when stories are created. I call it “agile planning” and if “agile development” is the process of getting stories implemented, then agile planning is a separate process that starts with ideas, concepts and features and ends as stories are fully written and estimated.
Basic concepts of agile planning
Here are some of the basic concepts in the Driving Digital Agile Planning Process
-
- Features are first broken down to a list of “story stubs” which consist of the story summary but with little additional detail.
-
- Stubs are always estimated – even though they are vague – to give the product owner feedback on complexity and to aid in deciding what is MVP for the feature.
- Product owners or business analysts that write stories also “commit” to having stories fully written during an “agile planning sprint”. The agile planning sprint often starts and ends 50% of the way into the agile development sprint which helps get stories fully written in time for the next agile development sprint.
Benchmarks of healthy agile planning
-
- Stories for the upcoming agile development sprint are fully written by 50% of the way into the agile development sprint. Stories coming in later than this are marked as “late” as they pressure the team to review, size, and solution in less time.
-
- I like to see at least 3+ sprints of story stubs in the backlog.
- I want healthy balance of stories – usually measured across a release of sprints and not a single sprint
- 30% of stories coming from the agile planning process
- 30% of stories reacting to developer, user or stakeholder feedback that is conceived during or at the end of the sprint. These stories can be anything the team reacts to as they are developing the product. They include stories that do not full achieve ‘done’ at the end of a sprint, user requirements that change, new use cases, or responding to newly identified risks.
- 30% technical debt
- 10% spikes and R&D
These numbers can be adjusted if the team has lower technical debt or reactive stories, but I like to see the 10% spikes/R&D increase proportionally under these circumstances.
Once stories are written, Driving Digital also provides a two-step process on estimating stories and how product owners can make best use of them.
Leave a Reply