The Hourglass Scrum-Ban Board

Hourglass Scrumban Board

Recently I have been doing a considerable amount of work on the Theory Of Constrains, Scrum and Kanban. I have been working with a team for quite some time, which as changed considerable during out time together for the better. We started with a group of individuals and now we have a cross functional team who take responsibility for all their goals. The makeup of the team is 4 developers and 3 testers in the traditional skill set sense.

Initially we started with a traditional scrum board using the standard scrum practices. The workflow was that of a standard team over 6-8 lanes which followed the standard sequence :

  • Sprint Backlog
  • Dev
  • Testing
  • Done

Although being cross-functional and working as a team was encouraged, patterns emerged which clearly showed the division of developers and testers. I was becoming frustrated with this as it was facilitating mini-waterfall practices to some extent.

As part of a team building exercise I encourage teams to build their own board designs and avatars to visualise the workflow. This creates a sense of ownership and fun which are useful components when teams use the board on a regular basis. Personalising the board increases the level of engagement and encourages the team to work with their board. We evolved form a traditional grid board, to an octagonal board as seen here with our previous Super Hero Scrum Board. I’m fortunate to work with an open minded team who welcome changes of anytime in the name of improving.

This was a great setup and team really got more out of it. However, although the team was really working well together and sprints were successful, we got comfortable and the next step of the evolution needed to be taken. A symptom to date was there was too much work in progress and it was observed that a developer was looking to pull in the next card when the previous card moved to testing. What this meant was that the developer was introducing 2 and sometimes 3 cards into the sprint and creating a bottleneck with testing. It also showed a split in the team. However this worked well in most cases and everyone was happy, but more could be done.

Reflecting on Kanban’s ‘Work in Progress’ (WIP) limits and considering the Theory Of Constraints, exploit the bottleneck and subordinate every decision to the bottleneck we altered our workflow and visualised the change.

The first change was to limit the number of active lanes to 3. Having 4 developers and 2/3 testers this was a suitable number as it meant developers had to communicate and work together. In line with this rule, it meant that if a team member wanted to pull in a story and 3 lanes were already active, they couldn’t. The outcome was that the person had to have a conversation and with others on the active lanes and offer to help complete the story.

The outcome to this change was quite profound. This promoted team work and helped get WIP items done quicker not to mention improved knowledge sharing. The team become a lot more autonomous. Previously developers and testers had more of a separation. Now if a lane was being used and the story was in testing phases, the developer would get involved with testing. This resulted in much better knowledge sharing and a better understanding and respect for each of the development/testing processes. From this, significant improvements to the testing process emerged because developers could help improve automated testing using their development skills, freeing up time for more in depth manual exploratory testing and having capacity to accomplish more productivity.

The second change we introduced is that only two tasks of a story could be worked on at a time. This improved the workflow as it encouraged tasks to be completed and moved whereas previously it was less obvious on the workflow and status. This only applied on stories which were broken into tasks and in a lot of cases this wasn’t the case as a pair would pick up the story as a whole.

The third change which is noticeable on examples shown is that we abolished the development/testing lanes. This helped the team communicate and work together to get move the card through it’s requirements to get it ‘Done’. The ethos within the team is that everyone is a team member and not developers and testers. Each person as strengths and weaknesses which can be shared. Although there are obvious constraints, having less physical restrictions (lane divides), this encouraged the team to progress and become more cross-functional.

Hourglass Storyboard Lane

Hourglass Kanban Lane
Hourglass Storyboard Lane

As a result of these changes, the teams output increased and continues to do so. We have also seen significant improvement in knowledge sharing and improvements into the structure and workflow as there is a better team understanding of how changes upstream affect the process downstream. Therefore the workflow has become more efficient. We have taken on the 5 steps of the Theory Of Constrains and continue to apply them to continuously improve especially through the retrospectives :

  1. Identify the systems constraints/bottlenecks
  2. Exploit the constraints
  3. Subordinate everything else to the above decision
  4. Elevate the systems constraints
  5. Start Over

The Changes We Made To Our Scrum Board

You will notice that the board looks quite different to the standard Kanban/Scrum board grid. We wanted to emphasis the WIP limit and an hourglass represents this well. You could rotate this 90 degrees left and see it as a standard grid lane, but the hourglass is more fun and represents flow well.

Hourglass Scrumban Board
Hourglass Scrum/Kanban board
Real World Hourglass Scrum Board
This is our actual Scrum-Ban Board


Since sharing the blog post it went on to Win the Best Card Wall competition with ThoughtWorks Studios.

The hourglass scrum-ban board was also selected to be published in the following publication by Jimmy Janlén

Toolbox for the Agile Coach – Visualization Examples, How great teams visualize their work

Visualisation Examples Book


How have you implemented your Hourglass Card Wall ?

If you have implemented an Hourglass Scrumban Board, send your photo’s over with a brief explanation and I’ll post it on here with a trackback to your site.

1. Callum Sneddon uses the hourglass board to visualise work flow through a higher level over 5 teams 

The following board was sent over by Callum who works in Data Warehousing and BI. I was really impressed with this, it looks professionally designed and takes it to a level above each team to visualise workflow. Thanks to Callum for sharing this!

Overview : The BI Chapter has a member (The BI Lead) from all the teams in the release train. In total, there are 5 teams. The BI Chapter is in charge of setting standards, building templates and so on, so Callum created an hourglass for each team so they could see what the teams were working on. Regarding WIP limits, Callum has tried to limit it to a single story per team. They try to break our stories down so they don’t need task, but in cases where task are needed, there is a limit of 2 task’s per story to be played at any one time by a team. As for the jail, the idea is that a story can be blocked, but it might only be blocked internally to the team, so they just put that in “just visiting”, but if the story requires a PM, then it goes into jail.

Hourglass 5 Teams
Hourglass scrum board visualising release backlogs over 5 teams

More Photos Of The Hourglass board in use:

Thanks to Frances Bonnington for Sharing
Thanks to Frances Bonnington for Sharing @fbonnington


8 thoughts on “The Hourglass Scrum-Ban Board

  1. Just curious, why not have an hourglass iteration or intent board. Then reduce story size to the smallest thing that will work and limit stories in progress rather than tasking stories? Genuinely trying to get my head around tracking granular story implementation detail tasks?

    Adam Yuret

    1. Hi Adam, thanks for the feedback.

      Pretty much all of the time in our case the story card moves as one without the granular tasks. However in some cases the team may break down tasks if it helps them see the flow or breakdown to completion almost like a mini to do list to complete the story if thats what they are comfortable with. It’s not prescriptive, the team are responsible for the card flow. I personally like the to see the card move as one as there is less overhead and there comes a point of being too granular.

      The 3 hourglass’s are used to represent lanes and the WIP limit is applied to this. However you’re right and that would be a great idea having an hourglass for the iteration and the WIP limit could be at the neck. Might have to try that some day. A colleague of mine and I were discussing something similar with the idea that each level is an hourglass almost like the Russian Dolls, the larger bottleneck being the release/programme level and the smallest in the middle being the sprint. Might get a bit complicated then though.

  2. Hi Craig – just to clarify when you got rid of distinguishing between development vs test did you actually get rid of them from a perspective of “Done” acceptance criteria? ie did tasks still need to be tested?

    How big were your tasks vs stories generally?

    ps I’m pretty sure I mentioned this blog either the last podcast or the previous one (lol can’t remember with so much going on).

    1. Hi,

      The tasks we use are more of a todo type nature to help the team identify what needs to be done to complete the story. So they help identify the agreed workflow of completion and help people moving between stories know where the workflow is. There is no prescription on what these need to be, the team are responsible for creating them to a level they are comfortable with and makes sense to everyone in the team. Depending on the story sometimes these were fairly granular and other times the card would move without the need for tasks. So in some cases the tasks themselves were to create the test and therefore wouldn’t need to be tested. However the definition of done clearly states that all tests of all type (unit, functional etc) must pass. There was no reduction in quality or reduction in definition of done. In fact I think by removing the lane quality improved. Previously there was some assumption between dev & testing, but merging and crossing over quickly highlighted gaps in testing which not only improved test coverage, but quality as a whole. Quality discussions were and still are constantly being discussed and improved.

      The stories vary in size from the smallest visual change to complex player changes. Smaller cards would move quicker so it was relative. The larger cards would benefit more from lane limits as more people would jump on to try and clear the lane.

      Hope that makes some sense, otherwise please ask away.

      Thanks for the questions.


    1. Absolutely! It took some convincing, but the resistance was a benefit overall. Developers tend not to like manual testing, which is a great motivator to help improve the testing. As a result the developers provided great feedback and solutions with the testers to improve automated testing to cover more manual testing. There was a much better understanding and of each others work flow and how work upstream can affect downstream. Over a few sprints the manual tests significantly reduced and continue to do so, which are covered by automation.

Leave a Reply

Your email address will not be published. Required fields are marked *