Better software through software architecture and devops


Tag Archives: #lean

  • Scrum Master with kanban board.

    A little bit of styling can really help with your process. Using card colours can remove motion waste and save you time searching for things. Highlight, don't hide and run stylish stand-ups.


    Following on from my previous post there is much more styling you can do in Azure Boards. My favourite thing to do is to really lean in to the process with styles. Take daily stand-ups, they happen at the same time every working day and typically ask the same three questions:

    1. What did I complete since the last meeting?
    2. What will I do before the next meeting?
    3. What blockers and other issues are standing in the way of the sprint goal?

    All of these questions should be answered in the context of the sprint goal so lets make that really clear using a marketplace extension: Azure DevOps - Sprint Goal. This creates an extra tab at the top where you can keep your goal in mind.

    Next, remember that the reason for the stand-up is to discuss the sprint work items and their progress not focus on the team members doing the work. To that end I prefer to Group By: Parents so that work items are visible on the left.

    Group By Parents

    This does mean that some team members might speak multiple times as each item comes up but the order of discussion is in backlog priority. If you want to quickly see all work for a person use the person filter at the top.

    This is what a typical board might look like (note the sprint goal in the tabs at the top):

    Typical task board

    Even without seeing the detail I can tell this board has:

    • one task recently completed [green]
    • a task that is blocked (and its corresponding work item also blocked) [red]
    • a task where someone is requesting help [blue]
    • a task that is too large and needs to be split into something smaller [purple]
    • a task that has not moved recently and could be blocked [yellow]

    There is also an unrealistic amount of work scheduled for today since there is 12 hours of task in progress.

    How does this help with the standup? Lets go through the questions above, one by one. But first, these depend on having your stand-up at the same time every day. Styling based on date fields is a bit of a blunt instrument so if you vary your standup time they won’t work.

    What did I complete since the last meeting?

    For this I want to highlight tasks that were moved to the done state since the last meeting.

    Tasks done since last meeting

    • State = Done
    • Closed Date > @Today-1 (this is the magic, since yesterday selector)

    During the standup you can concentrate on your green tasks for this question.

    What will I do before the next meeting?

    Most people move tasks to in progress when they start working on them. I prefer to use it as a today view and place all the work I intend to do today in this bucket. That way I can see that:

    • I’m not taking on too much work because the sum of hours should be less than a working day. Typically 6 or 8 hours depending if you factor in some slack time to cover non-project work.
    • If at the end of the day there are tasks left I can make a call to work a little longer or accept the impact.
    • Similarly, if I finish early then I can also make a call to pull more work into the in progress bucket or see if anyone needs help on their tasks.

    Before I start moving tasks I want to make sure they are all small enough to fit into a single day’s work. This style rule shows them as [purple]. Its purple because I associate the colour with royalty and they are too posh to actually do any work.

    Tasks that are too large

    • Remaining Work > 8 (or use 6 if you factor in slack time)

    What blockers and other issues are standing in the way of the sprint goal?

    This last question uses the remaining style rules. We already saw how to highlight blocked tasks:

    Blocked Task Rule

    • Blocked = Yes
    • State = In Progress

    and blocked backlog items:

    Blocked Backlog Item Rule

    • Work Item Type <> Task
    • Tags Contains blocked

    But there are other styles that can highlight blockers. Firstly, if a task has not moved from the in progress state in the last day then something must be wrong since they are all supposed to be less than a day in size. Note, if you decide to stop working on a task and defer it to a later date I encourage you to update the remaining work value and move it back to the to do pile to keep the in progress = today list correct.

    To highlight these stuck tasks the following rule works.

    Task In Progress To Long

    • State = In Progress
    • State Change Date < @Today

    Finally, the [blue] task is simply a team member adding a help-needed tag. Blue represents ‘emergency services’ in my head. Since the goal of a sprint is to complete work and not start work, I prefer that the team works as a team instead of a bunch of individuals working in their own areas. To that extent, its always better to help someone else complete a backlog item than it is fo you to start something that potentially won’t get done in time. This is especially true in the second week of a two-week sprint.

    Task with Help Needed

    • Tags Contains help-needed


    Just a quick note on colour blindness. I know many folks might have trouble differentiating the colours I’ve used here so work with your team to identify combinations of hue and brightness that allows everyone to visually distinguish each style.

    I really like using styles to highlight areas for action. If you have a style rule not listed here then I would love to learn about it.

    Photo by Parabol | The Agile Meeting Toolbox on Unsplash This is clever marketing by offering great images for free so when attribution is made then your company name shows up in relevant web sites. However I am not making any recommendations here; only attributing the photo.

    This entry was posted in agile  and tagged #lean #azure devops #azure boards #card styles #blocked #opinion  on .
    Discuss this on Twitter or LinkedIn
  • Brightly coloured graffiti decorating the High Street Subway in Belfast City Centre.

    Tags are the simplest of concepts in Azure DevOps and other work item tracking systems. When you combine them with visual styles they become a powerful user experience feature.

    Whilst I was researching content for Task, state, column or work item? I came across Promoting “Blocked” to State from Status on Agile Board for better visibility which, IMHO, is absolutely the worst way to solve the problem of blocked work items. One of the comments even mentions creating a swimlane to put blocked items in which is especially bad since you can collapse the lane and forget about all your problems.

    There are a number of reasons why a blocked column is a poor choice most of which discussed here:

    Using my rules for states also implies that the only thing you can do to a blocked work item is to unblock it which isn’t the case.

    A far better way to indicated blockage is with tags. Leave the work item where it is and add the blocked tag. Don’t forget to add a comment as to why its blocked and, if possible, some tasks for getting it unblocked. The plain visual doesn’t stand out much but you can apply some colour either as a tag colour: Blocked tag colour dialog or card styling: Blocked card style dialog

    which looks like Blocked card … no missing that.

    The same principle also works for tasks on on the taskboard but instead a field called blocked is used instead. Blocked task

    Tags are so flexible you can use them in all sorts of ways. Some ideas for you:

    • Forgo the initiative backlog level, its always got only one or two items in and never any useful description or acceptance critera. Instead just tag your work items.
    • Use tags to differentiate different types of work item such as story, question, decision etc. This is more often used in the basic process.
    • Use tags to call out things - needs-discussion, ux-required, out-of-date, expired, etc

    Unfortunately, since tags have very little governance they can get a little out of hand. I use Tags Manager to merge misspellings and other issues.

    Photo by K. Mitch Hodge on Unsplash

    This entry was posted in agile  and tagged #lean #azure devops #azure boards #card styles #blocked #opinion  on .
    Discuss this on Twitter or LinkedIn
  • "Queue for Coffee". You know they serve good coffee when you see this. A line of people queuing for coffee at a street vendor. Rusty's Market, Cairns Australia.

    Queues are used to load balance work between teams but its easy to overlook a decrease in efficiency they bring.

    Its fairly common knowledge that batching work causes inefficiencies. This is why a core technique for lean software delivery is map your value stream and then limit the amount of work in progress. I wanted to see just how much efficiency can be gained by removing queues so started to map this with an idea example.

    Traditional Batched delivery

    Imagine we have a fairly standard software delivery pipeline: specify, build, verify, and release. I’m being purposefully vague here as the actual work doesn’t matter. In a traditional waterfall style delivery you would generally work on the specify part first to create a big requirements document; chuck it over the wall to the next team to build; once they have done that the built code gets chucked at the next team to verify; and finally the finished product is released to live.

    It not that obvious but the requirements document, the built code and the release package are queues. They contain a batch of work for the next stage.

    Lets visualize this by creating an ideal delivery pipeline. Imagine we have 10 work items; all exactly the same size; so they all take exactly one day to complete at every stage. (I know this isn’t the case in reality but that would only makes things worse.) The delivery plan as work flows through the process is shown below:


    Each step in the above process has an active ‘Doing’ column and a waiting ‘Done’ queue. Since the output queue for one stage is the input queue for the next I leave the work items in the done queue until they can actively be worked on. This helps calculate the active time and waiting time metric for each process.

    Since the release stage doesn’t involve processing items at the individual level you can see the whole package is released in one go.

    If we add up the values in the columns and work out the active and waiting times and also calculate the average cycle time for this configuration we have a maximum work in progress of 10 and timings:

    Cycle Time29.5
    Active Time31
    Waiting Time255
    Total Time286
    Calendar Time36

    So what if we don’t batch the work into a document?

    Limiting WIP by Sequencing

    This time the only thing we will change is to pass work to the next queue as soon as we have completed it. Everything else stays the same.


    Immediately we can see the whole thing is far shorter. Calculating the metrics for a WIP of 1 we have:

    Cycle Time11.5
    Active Time31
    Waiting Time75
    Total Time106
    Calendar Time18

    Note the active time is still 31 - its the same amount of effort as before but the whole thing is done in half the time because we removed 100 days of waiting time! Consequently the average cycle time has dropped by over half too. Remember nothing else changed apart from removing the batch.

    I could stop here but this is a good point to look at further optimization.

    Remove the Queues

    The next simplest optimization is to remove the queues between stages. This is harder in the real world due to uneven work size and arrival rate but we can look at the theoretical flow.


    The stats are better still - active time is still 31 days but there is only waiting at the end of the process because the release time still need to deliver a bunch of work into live in one go. Cycle time is only 10 days.

    Cycle Time10
    Active Time31
    Waiting Time55
    Total Time86
    Calendar Time16

    As this point the only optimization left is to ask if the release team can increase their deployment frequency. It could be possible since items are queuing at release.

    Increase Release frequency

    Whilst we could release every day like the very best DevOps practitioners lets assume there is a limit in the release process which means every other day is the best possible.


    The stats for this configuration are interesting - for the first time the active time has gone up because we are asking the release team to do 4 more releases. Similarly, the calendar time remains the same because we are still limited by the time it takes to get the last work items released but there is far less waiting and the overall cycle time has dropped to just 5.5 days.

    Cycle Time5.5
    Active Time35
    Waiting Time15
    Total Time50
    Calendar Time16


    This simple exercise demonstrates how hidden waiting time delays deliveries and smaller batch sizes can rectify that. In reality you will need some queuing between stages to balance out demand in this configuration. Look out for hidden queues:

    • Documents handed from one team to another - the entire document is a batch.
    • Pipelined iterations in scrum teams - where the requirements are written in the sprint before dev and the testing in the sprint after; the iteration backlog becomes the batch.
    • Done states between Doing states
    • Approval steps

    If you practice Scrum then aim to complete work in a sprint (specify, develop, and verify) or you are leaving waiting time on the table.

    Photo by David Clode on Unsplash

    This entry was posted in agile  and tagged #metrics #lean #devops  on .
    Discuss this on Twitter or LinkedIn