Visualizing the entire flow

In the large agile project I talked about in the last post, one of the biggest improvements in our process was combining our story workflow across all teams. At the start of the project, we didn’t really know what our cumulative development process would be. The dev team had a fairly established regimen on how to develop features. Our workflow wound up looking like:


This workflow was on a whiteboard next to the dev team. The story boxes were large Post-It notes, but the actual stories we worked on were mini requirements documents (side note, the whole “card and a conversation” is just bunk, from my experience).

We established this workflow very early in the project, but there were two other major phases in the entire workflow of getting a story from “concept to cash”, so to speak. The three phases a story went through were:

  1. Analysis
  2. Development
  3. Acceptance

This project had many stakeholders and interested parties, so a lot of people needed input on the analysis and acceptance phases. Eventually, the acceptance and analysis teams settled on their own workflows. We found that a story card started on a workflow in the analysis team’s story wall:


Stories that were ready for development were the stories in our backlog. This was a scrum project, so contractually stories didn’t make it into our backlog until the dev team committed for these stories to be delivered in that sprint (more on this later).

On the acceptance side, where multiple parties who all had a financial stake in the claim, each accepted the story. They had their own workflow as well:


These separate workflows each took about 6 months to fully realize. But once they did, I had a bit of an epiphany (after reading The Goal and chats with John Heintz). Each of these workflows was in the one large team room we had, but were physically located in each of the team’s pods of desks. The Analysis workflow was in the Analysis team’s area, and so on.

This led to two problems:

  • It encouraged behavior of “throwing things over the wall”. Each team was only concerned about its workflow, and no one else’s
  • No one could figure out current status of the entire project. It was scattered on multiple physical locations.

So at one weekly retrospective, we brought up the idea of combining all of these workflows into one single physical workflow and onto one single board. Each of the three workflows was brought, unchanged, onto one really long story wall.

What became interesting is that many of the “wait” stages disappeared between the boundaries of each team. Instead of a “Complete” stage in the dev team workflow, it moved straight to “Ready for Acceptance”. The boundary between the teams was removed. We were able to readily see which stages had stories backed up and which were starved.

In the end, visualizing the story workflow helped create shared ownership and responsibility of the entire process. If stories were backed up in acceptance, everyone saw this in the morning stand up and could raise it as an issue. If we didn’t have a lot of stories in the pipeline for development, the executive sponsor could see this and make appropriate changes.

It was a small change, and couldn’t really have been put in place at the get-go, but once trust was established and everyone got comfortable in their roles, we were able to take a step back and formulate the big-picture view with one combined, shared story wall.

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’d love to see a more detailed post on this: “side note, the whole “card and a conversation” is just bunk, from my experience”

    IME, what you said is bunk. every time i’ve worked on a team that tried to use cards as requirements documents, we would end up with the blame-game where a tester says “it doesn’t do X”, the dev says “it wasn’t on the card”, and the domain expert / business analysts say “of course it needed to do X. isn’t that obvious?”

    i found a happy middle ground to be best. put a little bit of what the thing is supposed to do, from a business perspective, and then let the conversations flow around it so that we can break down the work add more cards that represent what’s going to happen from a big picture.

    • Anonymous

      I should probably add a note – from a consulting perspective, it’s just bunk. It worked well in IT and product environments. Otherwise, no one has a good enough memory to remember conversations.

      • given the client is not on-site with the team, then yes, i agree with that. but wasn’t your client right there in the same room with all of you?

        of course no one can remember that many conversations. that’s not what you’re supposed to do. the card is supposed to have just enough information to spark ideas and questions at the point that the team is starting to work on the card. that’s when the team starts the conversations to get enough information to start the work, and do any work breakdown and adds additional tickets if needed.

        this is not a one-time-you-must-remember-everything conversation, though. it’s only one of many conversations that should happen as the card(s) progress. if a single card has too much detail to remember, then it should be broken down into multiple cards and tracked at the individual card level, as well as at an aggregate level.

        this is getting way off topic from your original point, which i completely agree with, by the way. visualizing the entire workflow at a high level is hugely important.

        perhaps the conversation about cards should go somewhere else? another post? up to you, though.

        • Anonymous

          Yeah, another post would be good.

          We do use cards for some things, like bugs. Just not new feature development.

          • Macondo

            I’m working with a medium team on different projects and we use these “Kanban” to manage every single task and it’s great. We used a blackboard with postits in the beginning but now we use sometimes Agile Zen or Leankit Kanban. The first one is simpler while the second has lots of features but is a little more expensive.

  • Nolan Egly

    I’ve seen the “throwing things over the wall” problem even within the
    same internal organization. Sometimes people are so used to preemptively positioning themselves to be “in the right” for the usual finger pointing that happens when a project hits snags (client points to dev, dev points to qa, qa points to management, etc.) that it takes time to build up a “whole team” trust to truly work for the total project and not just working to protect yourself. Having an “entire flow” perspective is one tool to help
    get people into this mindset as opposed to focusing solely on their role. Good post!