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.

46 favorite thumb_down thumb_up 10 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session


  • Introduction
    • 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
    • Pre-requisites
    • Case Study
  • Conclusion
    • Blitz Benefits
    • Closing statements about Blitz


Learning Outcome

  • Lean & Parallel approach to User stories, Architecture and test planning
  • Organizing the corrupt Product backlog
  • Team involvement in planning Project/Epic

Target Audience

Product Owners, Scrum masters, Project managers, Developers & Testers

schedule Submitted 5 years ago

Comments Subscribe to Comments

comment Comment on this Submission
  • Nitin Ramrakhyani
    By Nitin Ramrakhyani  ~  5 years ago
    reply Reply

    Hi Karthik,

    We are trying to shortlist the early bird proposals hence request you to respond to the comments from reviewers at the earliest. While the topic is interesting, I also have a few doubts/ inputs, as below :-

    1) Target Audience :- Who would be the audience interested in this? The SCRUM/ Agile guys who already have powerful techniques like Story-mapping at hand (Unless you pitch that Blitz is better?) or will it be waterfall/ traditional PMs who would like to know a new way of gathering requirement? 

    2) Concept clarity :- I felt as if too many concepts ( Lean/ WIP/ ATDD) have got into it, that you won't be able to cover. If you focus on just one aspect i.e. Blitz, that may be more meaningful. This is just my candid though and I could be wrong, may be you already know it and plan to just throw an overview. Check out the format of the workshop that was run by him for this: -

    3) Delivery :- You have tagged it as a 'Case Study', that it doesn't look like. This qualifies more as a Workshop. If this Blitz is the same concept as Alistair Cockburn promotes, then you would be better off running a workshop that would let people get their hands dirty with it and learn a new technique. 

    4) Past Experience/ Format :- Have you run this workshop earlier?If so, point us to any link or just elaborate in the abstract. And assuming you wanted to present a case study, won't it be a better idea to share your experience of doing so and if/ how you found it better than traditional ways.

    Just some food for thought to help you refine the proposal. All the best.



    • Karthik V
      By Karthik V  ~  5 years ago
      reply Reply

      Apologies for missing out on all the conversations. Thanks for the feedback and interest shown. I hope Sanjiv has responded to most queries.

      @Nitin - Thanks for the valuable & well articulated feedback. Find the responses below:

      • Target Audience: 
        The participants would be all involved in Scrum - we would like to pitch Blitz not only to gather requirements - this is to resolve the practical problems Scrum teams face.
      • Concept Clarity: 
        We are utilizing some of the Lean/WIP/ATDD concepts - but Blitz as a process doesnt mandate this. Thanks for sharing the link.
      • Delivery: 
        Thanks for your suggestion - we will refine the proposal soon to convey it as a Case-study. This is more of a case study on Blitz workshops conducted. This may be built upon Alistair Cockburn's workshop but this gets into the execution cycle.
      • Past Experience/Format: 
        Yes we have had practical experiences but in various projects, we saw  benefit of running Epic Blitz in comparison with traditional approach. This reduced the delivery timeline by 2-3 two week sprints.

      We have slides which are for internal consumption - need to get that converted into one that is available for public domain.

  • steve ropa
    By steve ropa  ~  5 years ago
    reply Reply

    Hi Karthik,

    This proposal intrigues me.  For me, the disconnect is between some of the concepts you intend to introduce, such as WIP queue and ATDD in this context.  Perhaps a little more description as to why they are important to Blitz would help. I'm also wondering if this is beginner level, or maybe intermediate?






    • Sanjiv Bebarta
      By Sanjiv Bebarta  ~  5 years ago
      reply Reply

      The “Blitz” is not only Agile its lean too. It uses some of lean principles single piece flow, Pull, Perfection etc. WIP limit in “Blitz” is one.  Single Piece (Lean) related to “EPIC” and Process (Lean) related to clear backlog that team can use for sub sequent sprints.


      The framework helps to beginners and we tried to explain in brief the Agile and Lean concept in “Blitz”


  • Savita Pahuja
    By Savita Pahuja  ~  5 years ago
    reply Reply

    Hi Karthik

    Are you only going to present about Blitz by theory only or will include some hands on activity as well ??



    • Sanjiv Bebarta
      By Sanjiv Bebarta  ~  5 years ago
      reply Reply

      The plan is to present the "CASE STUDY"  , how we followed the "Blitz" and what are the benefits

  • Joel Tosi
    By Joel Tosi  ~  5 years ago
    reply Reply

    Hi Karthik,

      Would you consider introducing blitz and providing the deltas first in your session as opposed to last?  I find that understanding the why / how is it different prior to the mechanics aids in learning.  What do you think?




    • Sanjiv Bebarta
      By Sanjiv Bebarta  ~  5 years ago
      reply Reply

      Yes. The flow will be to explain first what is the issue that we faced to come up with “Blitz” and then to explain the “Blitz” in detail.


  • Sonik Chopra
    By Sonik Chopra  ~  5 years ago
    reply Reply

    Hi Karthik,

    This is rather a very important concept and thanks for picking this up. I've few queries here. How will we differentiate between story writing workshops and your presentation? And please also elaborate what all you want to cover in ATDD as it can distract the audience from the main context of this workshop. I would also appreciate if you can provide more details on blitz framework and some slides or further details would be very helpful


    • Sanjiv Bebarta
      By Sanjiv Bebarta  ~  5 years ago
      reply Reply

      A. How it differs from a story workshop?

      Story workshop generally covers matching the pattern, splitting stories , understand the style , Person and role , Defining the acceptance criteria etc.

      In blitz the main focus is to solve the practical problem faced by the team during execution of EPIC in normal sprint cycle of agile. This also brings in the use of some lean principles  like single piece flow, pull and Perfection in “EPIC SPRINT” . Very interesting part is to know what is “EPIC SPRINT”.

      B. Elaborate ATDD in Blitz context

      Generally we observed the team is lagging the skill to write the user story. The concept in blitz process is you get the user story for “free”.

      C: More details about Blitz

      Blitz is the “EPIC SPRINT” in normal agile cycle of sprint. The solution is not only Agile its lean too. And many more…

      The some of the deviations from Agile is:

      Ø  Documentation is necessary

      Ø  Most teams aren’t mature enough to drop up-front architecture and design right away

      Ø  Distributed teams introduce too much overhead for extended periods of high collaboration

      Ø  Test plans (acceptance, regression, etc.) are absolutely necessary


  • Liked Prasanna Vaste

    Prasanna Vaste - Should we stop using Story Points and Velocity?

    Prasanna Vaste
    Prasanna Vaste
    Business Analyst
    schedule 5 years ago
    Sold Out!
    20 Mins
    Experience Report

    On Agile projects we estimate user stories in order to allow team to

    1. 1. Track velocity
    2. 2. Decide scope for the Iteration
    3. 3. Help Prioritize stories
    4. 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.