From sprints to pull-based flow

In the last post, I talked about a large, long-term agile project and how we consolidated individual teams’ story flows into one, big story wall. All teams were now united into one visible process for getting a story from inception to “done”. In the lean literature I’ve gone through, “done” really means “in production”, but in our case that wasn’t possible (more on that later).

Once we had the entire flow visible and “correct”, in that it actually represented the real flow of a story as well as the real “current state” of the entire story delivery system, we were able to make more informed decisions about the true health of the project. We had a lot of speculation about which areas were slowing down, needed tweaking and so on, but it wasn’t until we saw the entire pipeline that some obvious truths came to light.

Segregated workflows

One situation that our dev team knew was a problem was that we would often be starved for work. Because we were performing work in 1-week timeboxed sprints, we often saw that at the end of the sprint, our story wall would look like:


The stories would be pretty much done, with the exception of them being accepted by the product owners and stakeholders. Our team would have to find work to do, usually around refactoring, optimizations and the like. But this was completely obscure to the product owners, so we adopted a model where the product owners could introduce “tweak stories” into the process.

Tweak stories were things like “adjust the spacing” or “move this field” that would take less than an hour to accomplish. We found two problems with this:

  • It allowed a back door for anyone to increase the scope of the project
  • The tweak stories were worked on ahead of other real stories, artificially increasing the tweak story’s priority

Pulling stories early

The dev team knew this was a problem, but the lack of a complete vision of the entire pipeline prevented us from bringing up that question in an appropriate setting. However, with a combined flow, our wall in the above scenario looked like this (other before/after stages removed):


Tweak stories were in a different flow altogether. At this point, we had the entire vision of the story production pipeline, so it became much easier to introduce a pull-based story workflow. At the daily stand up, I asked the question to the executive sponsor, “We have some development capacity and idle developers. Should we work on these tweak stories, or work on one of these stories ready for development?”.

Absolutely a no-brainer on that one. I didn’t get the question fully out before the answer came “work on a story”. And that’s how we introduced pull-based flow into our scrum-based workflow. We formulated the language around “pulling stories early” rather than “let’s ditch sprints”, to make the transition to pull-based flow more palatable for everyone.

Side note – changing processes can be a big deal to a lot of people. Good communication skills in this area is VERY IMPORTANT to maintaining the trust of all parties involved.

By pulling stories in early, we were able to adopt a more continuous flow of stories, while still maintaining our contractual obligations to commit to stories for each sprint. But instead of sitting idle or allowing feature requests to subvert the story process, a unified view allowed us to fully realize the maximum throughput of producing stories.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • i’m loving this little series of posts, jimmy. brilliant insights into why you made what changes, and how they helped. keep them coming :)

  • Jonty

     We use that period of the sprint to analyse and confirm conditions of acceptance (in our case Given When Thens in Specflow) for the next sprint. Does that amount to the same thing?

  •  Hi Jimmy!

    Just a little question: don’t you think this pulling model _may_ eventually collide with the principle of “keeping a sustainable pace indefinitely” ?

    How the team members find time to self-learning, research, improvements, etc., if their extra-time is now filled with new stories?

    Thank you, and what an amazing  thought-provoking series of posts!


    • Anonymous

      Yes, and it’s one of the reasons we adopted 10% self-improvement time.  

  •  Just wondering about some basics. Do you guys sit at your own offices, are you out at the customer? If you’re in your own space, does the customer come daily? How far is the customer away?

    • Anonymous

      We sit at our own offices. The principals/analysts travel to customer sites when needed. With 1 or 2 exceptions, all of our clients are in the same city (by design), so that we don’t travel.

      All stuff for a future post I think…

  • Jimmy, isn’t this just Kanban? 

    • Anonymous

      I couldn’t say, I don’t know enough about kanban to say one way or the other. This was really just based on that book The Goal. 

  • Tom

    Interesting post. Thanks Jimmy. If I may add my reaction: Scrum is a pull-based flow. It’s just that work is pulled in chunks. This allows you to set and work towards goals of a convenient granularity. Plus, it provides a routine for assessing and demonstrating progress and reflecting on the process. I think it’s more fun than the relentless monotony of Kanban ;)

    If they are repeatedly completing all the stories in each sprint with time to spare then I’d expect the team to commit to more points in the next sprint. There’s nothing wrong with identifying a couple of bonus stories that don’t form an essential part of the Sprint goal but you’ll start work on if all goes well.

    • Ever see that classic I Love Lucy where Lucy is making the pies and the machine gradually speeds up? That’s what I felt like when the sprint point commitment was raised after the team did well. The team never felt like they won, just that someone else had ratcheted up the pace.

      • Tom Gutteridge

        I see your point and I like the analogy (though I haven’t seen the episode). However, I don’t think it should be “someone else” who ratchets up the pace. Rather the team, encouraged by the warm reception of last sprint’s pies, agree to try and cook up an even more impressive feast this time around. If, come sprint review, not everyone has been fed they can choose to rein in their ambitions a touch. This shouldn’t be seen as a failure, after all they still baked some fine pies! It’s all part of inspection and adaption. It’s not necessarily that they slacked off. Perhaps, for example, their estimates were a little out. With the additional knowledge they’ve gained, estimates for subsequent similar tasks should be more accurate.