Archive for the ‘Kanban’ Category

I am currently working with a distributed team and we use JIRA for our sprint task board. We use it in our daily scrum (I can’t call it a stand-up) via Zoom. Over time, I’ve noticed that there are some things that come “for free” with a physical board, but are hidden or not as obviously visible on a digital board (at least not in JIRA). We have found workarounds for some and not for others and, perhaps, depending on the team, not having some of this information “in your face” might be OK. However, I thought I’d make a list of things to look out for if you happen to be using a digital rather than physical board for your team. Also this blog is all about learning 🙂

Please note, I’m only basing my observations on JIRA for this blog post because that is what we use. I suspect that most digital task boards have similar issues.

1. Who’s doing what?

My teams in the past have used personalised avatars to indicate who’s doing what task(s) for the day. We found this had two related benefits:

  1. You were naturally constrained to the number of avatars you happened to have available to you (although it was still fairly easy to take on more merely by initialing the sticky).
  2. It was very easy to see at a glance where a task had too many people, or where one person seemed to have spread themselves to thin, or where someone hadn’t committed themselves to a task.

When asking the question, “what do you notice about our focus?”, it was easy for the team to notice where they may have over- or under-committed themselves for the day. Or to notice and confirm where they were swarming for the day.

In JIRA, only one person can be assigned to a task. It’s not visually obvious where multiple people are working on a task. Also, because we usually only expand the story we’re currently talking about – and usually our full sprint of stories doesn’t fit into the view if we expand all rows – it’s very hard for the team to see good and bad patterns in how they have allocated themselves to tasks for the day.

2. Where are we stuck?

One of the tools one can use on a physical board when it seems a team is taking a while to get things done, is to start dotting tasks. The idea is that a task gets dotted for every day that it has been in progress and not finished. As the task develops measles, it’s pretty obvious where someone may be blocked or may need help.

JIRA does have the concept of task-dotting, but it’s very hard to see (it’s a light gray) and unfortunately the dots don’t stick around. They disappear as soon as someone moves the task to the next column on the board (so, for example, a task that may have been in progress for two days will suddenly have no dots when it moves to the show me column).

When dots have measles, it’s easier for the team to notice where tasks are dragging on for days and do something about it. You don’t really want tasks that have started to take more than a day to finish.

3. How big is our story?

This is probably (hopefully?) a JIRA funny. When we’re viewing the active sprint and sprint board, the story points aren’t visible. Assuming you use story points, they can be useful in helping the team notice when a story is taking too long – a supplement to the burn-down (see below) and tasks with measles (point 2 above). We have a workaround in that we add the story points to the end of the story title. It would be cool not to have to do this.

4. What’s our progress?

JIRA generates a pretty cool burn-down. But it’s not visible on the sprint task-board (which is the view we use for our Scrum meeting). How you’re doing on your burn-down is quite an important piece of feedback for how to adjust your plan for the day. Our workaround is to publish it on Slack before we meet, but it would still be useful to have it visible for the conversation.

5. What’s our goal?

I love (good) sprint goals. I find they give the team something specific to aim for that still allows for creative ways to respond to minor changes that emerge during the sprint. Goals are also a really useful way to bring the team back to the bigger picture in terms of sprint progress: “Are we on track to achieve our goal?”; “What are you doing today to help the team achieve the goal?”. So we create an awesome team sprint goal and ideally we want to have it front-of-mind when planning our tasks for the day. On a physical board, this is easy: it can be as simple as printing your goal on a piece of paper and sticking it to the board (ideally in colour and with sparkles). On a digital board, one needs to get a little more creative. In our case, we write the goal as a story at the top of the sprint and try remember to refer to it before we start our daily conversation. It seems to be working, but it does blend into all the other sprint work.

6. There are other aggregate data questions that are harder to answer

As Jacques de Vos once said: “If you have to scroll, you can’t see the whole“.

With a physical board, the team can usually notice useful things when answering questions like:

  • What do you notice about our tasks in progress?
  • Where do we seem to have the most focus?
  • What do we notice on the board about stories not started?
  • What do we notice about the state of our overall sprint in terms of stories in progress and not started?

Usually a quick glance at how stickies (whether stories or tasks) are grouped in the various lanes of the task board can provide a lot of insight into how things are going – especially if the distribution pattern is looking different to what the team is used to and/or expects to see. With JIRA, this view isn’t easily available. Expanding all of the rows creates a very busy view which is also not guaranteed to fit without the need to scroll. Collapsing the rows hides the task distribution (which may hide other things) and also the story status is represented by a word rather than the story’s location relative to the board’s columns and other stories.

7. There’s usually a driver

The way we use JIRA, someone screen-shares the taskboard in our Zoom session and that person automatically becomes the ‘driver’. What I’ve noticed about this is:

  • People are less likely to interact with the board during stand-up: they’d rather ask the driver to make updates or create emergent tasks
  • Some people are scared to drive (probably a tool thing – either JIRA and/or Zoom), so never do
  • The driver can get distracted by the mechanics of having the right story expanded, or making changes in JIRA, or whatever – so are not always fully present in the conversation
  • If the driver ends up being someone in a “leadership” position (e.g. a senior developer, the Product Owner), then sometimes they subtly control the decisions the team makes in terms of what they plan to do for the day because they can move things or assign things before the team have finished their discussion
  • All of the above means that the negative aspects of “you do it, you own it” sometimes sneak in…

I shared some of these challenges on the #zacoachclub channel in the Coaching Circles Slack Group and got some useful ideas to try out:

  • Write down in detail what information you really need the board to show so that it becomes your information radiator. Then lose all pre-conceived notions of how a board should look and how your tool sets up its boards. Based on the info you need: what could a board in your digital tool look like?
  • Try to represent the info you need in something other than your tool (i.e. JIRA) – maybe Google Draw or something. Once you have something that works, try implement that in your digital tool.
  • If the problem is too many things on the board, could your sprint/commitment be smaller to fit everything in one view?
  • Create a filter that filters out “old” done items and try to only work from the top story (limit work-in-progress).
  • Shift some of the information elsewhere e.g. Say pairs work on the story – they break down tasks in another place (Trello?) and feed back only relevant info to the greater team on the story which is in JIRA. Feedback to their mini team is much more granular and on another board/tool.

Do you use a digital board on your team? What challenges have you experienced? What did you try?


I recently attended the regional Scrum Gathering for 2016 in Cape Town. This is a post in a series on the talks that I attended. All posts are based on the sketch-notes that I took in the sessions. 

This key-note was done by the famous Jim Benson and actually spilled over into subsequent impromptu session. Jim is a very entertaining speaker and doesn’t pull any punches when it comes to challenging the “accepted best practices” of Agile/Scrum/Kanban.

His talk started with some context: what do we mean by systems and what should we be optimising them for? His opinion: we want purposeful systems – systems that work towards achieving their purpose. Extending from that, we should be optimising systems to achieve that purpose – and nothing else. Processes can be defined as rules of conduct (for people) that optimise a system to achieve its purpose. If we consider processes as rules of conduct, then it makes sense that an imposed process (your process) would enslave me whereas an inherent/organic process (my process) would help me. Also, the inspect and adapt loop becomes the mechanism to continuously adjust our rules of conduct (process) based on the reality in which the system is operating.

Now, before one can optimise for purpose, one needs to understand what the purpose of the system is. Jim suggested some basic questions one should be able to answer:

  • Who is my customer?
  • What problems are we trying to solve?
  • How do we engage professionalism over professionals?
  • How do we work in small batches?

As mentioned, the key-note extended into another session and I don’t recall exactly where in the talk that happened, however at some point we started discussing how, in the past, we worked in social hierarchies (good old organisational charts) whereas now we tend to operate within social networks. One downside of social networks is that they have some communication challenges, particularly between networks. One tool Jim shared with us to help with this was an exercise to create a shared story for a team (who should be operating as a social network).

A shared story is created by the team and consists of four parts:

  1. The vision of the team: Why are we doing what we’re doing?
  2. Expectations of each other: What are my expectations of you? What are your expectations of me?
  3. Boundaries: When does someone need to talk to me about something that they are working on? When do I need to talk to someone else?
  4. Victory: How do we know when we have succeeded? What does victory look like?

The shared story should be regularly updated and revised by the team.

Some other cool snippets/ideas I picked up during the keynote and subsequent continuation:

  • Using a scary scale to help prioritise stories. Teams rank a story as being either a kitten; or a crocodile; or a zombie; or a zombie crocodile (in order of scariness). The idea is that you want to be tackling and learning from the scariest stories first so that you can hopefully make them less scary.
  • When having stakeholders rank work, give them only two options: Do (above the line) and Ignore (below the line).
  • If your team is struggling with poor quality or not-quite-done stories, then inspect and adapt as stories move to done. Ask the question: how do I feel about this finished task/stories? If the person doesn’t feel happy, then unpack what still needs to happen in order to feel happy or comfortable about the story/task. Over time, these things would probably evolve into a more team appropriate definition of done.

What are your thoughts on some of what Jim had to say and share?

I’ve always struggled a little with the concept of sustainable pace. Most examples are around team burn-out and not having a ‘death march’. I can buy into that kind of work-life balance idea(l) – although humans generally like a little bit of pressure to get things going – but always felt there must be more to it than that. Then I stumbled across this quote in an article:

‘Sustainable pace’ means that speed takes second place to good QA practices that keep technical debt low.

I like that. How do you feel about this statement?


(This is part 1)

I liked the idea of story-mapping from the first time that I read about it. I’d done a couple of up-front sprint zero type exercises to create and size a Product Backlog at my previous company, and the feedback from the team about the exercise was that, once it got down to the relative sizing, it was hard to keep a grasp on the bigger picture and people often got confused about the relationships and boundaries between stories.

Simply, a story map is a way of maintaining a visual connection between stories as it shows the higher level user process (which also intuitively maps dependencies in 99% of cases) while showing the stories underneath. The other cool thing is that it’s a visual way to ensure one is doing vertical slices – by choosing stories in horizontal groups (so across the user process). Stories are also prioritised vertically adding the dimension that comes from the traditional Product Backlog. One of my team members, seeing our story map for the first time, described it as a ‘seven dimensional view’ of the project. Amazingly, although it has these many dimensions, it’s a pretty simple view to understand and can also be used to show progress.

If you haven’t already done so, I recommend you spend a worthwhile hour watching this video. I’ve also added some other links about story-maps below, but the video is still one of the best resources I’ve come across.

For this two-part entry, I’ll describe a bit of how our very first story mapping session went and some of the learnings I gained from running it. I intend to do some follow-up posts over time as our map (hopefully) evolves.

Our ‘project’ is slightly challenging to story map as

  1. We’ve already started working
  2. It’s about replacing something that already exists
  3. It’s related to our security architecture – so it’s very technical and quite difficult to map from a ‘user’ perspective.

My session (which ended up being two) followed the approach in the video quite closely, so had the following parts/steps:

  1. An intro in which I highlighted the desired outcomes and high level process that we would be following in the session. I also introduced the goal that was proposed by the Product Owner. This led to some debate as it was more business focused, whereas work to date (about a year) had been more about the technology. The team felt there were other ways to achieve business value using the existing infrastructure (a valid point). In hindsight, the goal may not have been the best goal for the session, but it did result in some much-needed debate and clarification and still helped keep the group focused on business value rather than technical goals. I did receive feedback that more up-front detail on the overall process we followed may have been useful in the intro as people weren’t always sure when it was the right time to introduce an idea/concept (none of the attendees were familiar with creating a story map before the session).
  2. The team (individually – silent brainstorming) wrote up stickies (all the same colour – purple) about the ‘things people do’. To help stimulate their thinking, I put up some typical users (we ended up trashing one of them). I also took them through the email example (just the user task level) to help get them to the right level. Once everyone was done scribbling, they did the grouping and naming exercise as demonstrated in the video. We actually struggled with our user tasks being too high level (e.g. manage xyz) rather than too low-level: it did help to try to get the team to start tasks with verbs where they had to break it down a level.
  3. We prioritised the groups and user tasks from left to right and ran through some scenarios. This highlighted a lot of gaps that hadn’t been clear before. At this point the group were getting quite tired and it was nearing lunch time. If I’d had time, I probably would have given everyone a long break at this point. As it was, we only had time for a coffee and tea break. Until now, all the work had been done on a large table in the centre of the room: I now put the skeleton up on the board (not wide enough) for the next part of the exercise. You need a very wide space for story maps!
  4. The next part was not done as comprehensively as we would have liked. We skipped writing stories for some user tasks that we knew wouldn’t be in our first slice and didn’t get into the detail of the second application we’d identified. We also did not write stories for work that we’d already done, which created some confusion later. We still got what we needed out of the exercise, but more time would have been good, and we will need to revisit parts of our skeleton. There’s also a (low) risk that some of the tasks we’ve left out for now are actually risky/important for our first slice.

That marked the end of our first session as we were already thirty minutes over time. Throughout the session, I encouraged the team to write down issues, risks and assumptions on bright pink stickies so that we could ensure we addressed them appropriately and did not forget about them. It also automatically created a parking lot, because anything that was relevant overall but not to where we were in the process could be parked (and eventually they did all find a home, either on the story map or as impediments in our impediment backlog).

Things that I felt worked well:

  • Being strict about using certain coloured stickies to represent particular things. This also made it easier to reproduce the map in a different location!
  • The email example was useful for framing what level we were speaking to.
  • The individual brainstorming and grouping approaches both worked really well. They got people on their feet and everyone engaged once they got the hang of it.
  • Do try to stick to the recommended 5-7 person limit.
  • The product owner was happy to see the team focusing on a business goal rather than a tech goal.

Things that didn’t work well:

  • We didn’t cover all the scope when we created our stories. We may have missed something.
  • Time. In the end, we needed three-and-a-half hours to complete both sessions (which wasn’t far off my gut feel of four hours).
  • Related to time, the team got tired. We could have done with more breaks.
  • The conversation about and agreement on the goal should have happened before the session.
  • Ideally this exercise should happen before work has started, as having done and partially done stories did confuse matters when creating the map.


A must-watch for anyone interested to learn more about story-mapping and/or slicing and visualising projects/products better.

Story-Mapping Video


I recently played a Kanban game with my new Kanban team. I’ve never played an Agile game before so was not sure how it would work, but had heard about the airplane game and how successful it is at teaching teams about flow, pull systems, cycle times, limiting work in progress, etc. After doing some online research, I stumbled across some variations of the traditional game, and was attracted to the Kanban Pizza Game. It looked fun and something everyone could relate to, plus it created the opportunity of actually ordering pizza for afterwards 🙂 The link goes into some detail about how to facilitate the game, so I won’t go into that here. I’d rather highlight some of the lessons I learnt trying to facilitate a game I’d never played or watched being played for the first time.

You need a helper!

There is a lot going on this game, not least of which ensuring teams don’t leave the pizza slices in their oven for too short (or too long without penalties). Thankfully I roped our Product Owner in at the last moment and he also helped with quality control and counting up for scoring, as well as keeping track of which slices had been “spoiled”.

Enforce WIP limits at least once

When I facilitated, I mentioned work in progress limits and enforced that each team had at least three stations (of their choice). In the close-out, one of the teams mentioned that they had set WIP limits but had not really stuck to them – or had changed them on the fly. My feeling is that some of the Kanban principles may have been more clear had these been enforced for the round. In hindsight, it may have worked better from a demonstration perspective to have enforced certain base stations and base limits to start with and then allowed the team to tweak them as the rounds progressed.

Track cycle times

The facilitator’s guide says measuring this is optional (perhaps because you really will need more helpers to do this). My feeling is that we lost a lot of the point by not tracking the cycle times between different rounds and changes to the process. We saw a significant improvement in the number of slices produced between rounds 1 and 2 (and one of the teams did observe that having a pull system – the orders – contributed to this), however, as things became more complicated, the points scored at the end of the round did not always correlate to improved efficiency. Cycle times would have also helped illustrate just how much value was being lost through wasted inventory.

Have a practice round

The group all said that they were more efficient in the second round merely because they had a better grasp of the process and rules. It may be an idea to run the first round twice before introducing Kanban concepts to mitigate this ‘learning’ effect on the outcomes.

Don’t give them timelines

The facilitator’s guide does warn why the team shouldn’t know how long a round is (watch out for clever teams timing a round for better planning!). I did let them know when we were busy with the final round, which in hindsight I probably should not have, as then they paced themselves to make sure there was no excess inventory at the end of the round rather than working towards getting as many orders filled as possible. I guess in real development this approach might make sense, but it didn’t really help from a demonstration perspective.


Things I felt came through quite strongly

  • Having stations.
  • The advantages of a pull system.
  • The group had fun!
  • The fact that the whole process was important: it was not helpful to have a highly efficient stickie cutter if the end-to-end process was too slow to consume the parts.

Things that didn’t come through as well

  • Limiting work in progress.
  • Impact of limiting work in progress on cycle times.
  • Having explicit policies (team felt that they were implicit).
  • Idle time.

Have you run this game before? What did or did not work for you?


Learning about Kanban

Posted: March 6, 2014 in Kanban
Tags: , ,

One of the teams I’m newly responsible for is called the “Kanban team”. This made me a bit nervous when I joined as my knowledge of Kanban was completely limited to some reading I did when trying to find a better way to visualise work while a team I was Scrum Master of at my previous company was going through a Lean Start-up phase. The Kanban team appeared to be functioning and was getting stuff done, but I found the board completely confusing and there didn’t seem any easy way to understand inefficiencies. My first task was, obviously, to try to find out a little more about Kanban and understand its principles, and I did this through conversations with colleagues who had been on the training and a lot of Google searches!

The first ‘retro’ I had with the team, I highlighted the main principles of Kanban, which are:

  1. Make workflow visible
  2. Limit work in progress (WIP)
  3. Measure lead time

We agreed that although the workflow was visible (via the board), we were not currently limiting WIP nor were we able to track our lead/cycle times. The first exercise was to review the workflow itself, which we approached with a ‘blank canvas’ approach, mapping the steps various items would go through to eventual release. This team is responsible for maintaining the system on a day-to-day basis, as well as building smaller features, which means some work is very ad hoc and other work is more structured and ‘plannable’.

The second session I presented a proposed version of the board (which was basically the existing board plus some additional columns) plus some suggested WIP limits for us to argue about. After much debate, we eventually agreed on a board that had similar columns to the existing board and was flipped (so that work items bubbled up the vertical rather than along the horizontal axis). The team agreed to track WIP at a ‘story’ rather than task level (although tasks were still added to the board for visibility), and we agreed on some WIP limits. It was a tiring session but it was nice to see the team take some ownership, although it took them at least a week to adjust to the new board once we got going.

Since then, we’ve made some minor changes. I posted up some policies (exit criteria) based on info we had, but we still need time to review and flesh them out (particularly our Definition of Done). I was also trying to track cycle time by tracking when stories moved, but this was proving difficult and time-consuming and prevented the team from moving items backwards (which is something they wanted to do), so we bought a date stamp (like they used to use in libraries) and agreed to stamp stories at three points in the process:

  1. When the story/item hits the board
  2. When it moves into the build phase (starting with design)
  3. When it’s tested and ready for release (done)

We haven’t been tracking tasks long enough to have any useful data yet, so I’ll have to see how this goes. The main thing I have noticed is that the team is still struggling with the concepts of lean, so my next big session will be to a play a game with them (similar to the airplane game) to try to demonstrate how the pull system is supposed to work. I’m hoping that they will then have an ‘a-ha’ moment and we can start focusing on improving our process. Think of it as a change management exercise 🙂

Useful links:

  • I found this comparison of Kanban and Scrum really useful as I could work from my existing knowledge.
  • I liked some of the task board ideas in this article.
  • And, in case you don’t know what it is, here’s more on the Airplane Game.