Revving up Scrum with Blitz – Collaborative workshop to organize the Epic backlog
Most features have a lead time before Requirements, Architecture and Epic Backlog is available to the scrum team. There is a misconception that these Sprint zero, or planning Sprints are the way of Scrum but are actually waterfall methods. Also this approach doesn’t essentially lead to team empowerment of the product backlog during sprint execution.
Blitz – brings in a time boxed intense collaborative approach with involved stakeholders and scrum team agreeing on requirements, architecture, acceptance criteria and product backlog priorities. This is part of the Scrum execution cycle rather than a Sprint 0/Planning exercise.This brings in a parallel and lean approach to expedite a refined development ready product backlog.
This is an approach executed at various projects to reduce the feature delivery timeline and understand/minimize the unknowns.
Outline/structure of the Session
- Challenges in creating Development ready user stories
- Understanding the Last Responsible Moment until when Epic Blitz can be taken up
- Lean and Work in progress queue
- Acceptance Test Driven Development
- Blitz Overview
- Case Study
- Blitz Benefits
- Closing statements about Blitz
- Lean & Parallel approach to User stories, Architecture and test planning
- Organizing the corrupt Product backlog
- Team involvement in planning Project/Epic
Product Owners, Scrum masters, Project managers, Developers & Testers
schedule Submitted 3 years ago
People who liked this proposal, also liked:
Prasanna Vaste - Should we stop using Story Points and Velocity?Prasanna VasteBusiness AnalystThoughtworks
schedule 4 years agoSold Out!
On Agile projects we estimate user stories in order to allow team to
- 1. Track velocity
- 2. Decide scope for the Iteration
- 3. Help Prioritize stories
- 4. Help Release planning
But most of the time we faced issues with estimation. It takes lot of time in estimating user stories, managers tend to relate estimate to number of days it will take to complete the story, in some teams estimate is equal to deadline. Most of the teams which use story points to estimate the work face these issues. This results in lack of confidence on development team when stories are taking more time to complete.
Here I am going to talk about better alternative for both the suppliers of software products (financially and ethically) and their customers (internal and external). This alternative is being used in real companies delivering to real customers with great effect where team uses count of stories completed in an Iteration as measure of progress. Will talk about how this alternative can be used to track velocity, prioritize stories, planning Iteration and for release planning.
I will share some exmples from my past projects where team did not use story points/velocty but used count of stories completed in Iteration to measure progress and also as best indicator of future performance.