3

Recently I am asked to inspect the Kanban system our company is following and I am having some difficulties to fix it. I am working in a startup company and in software department there are 5 developers and 1 tester. We use JIRA for our Kanban board. Tasks initially appear in backlog and when the task is approved and a developer is assigned, it is moved to development. When the developer starts working on the task, it is moved to in progress and then it is send to review/test/deployment phase. If it fails the test or review, it is moved back to development again, otherwise it is done and moved to done status.

We have a really large backlog, it is full of tasks that are almost forgotten and it does not seem to get any better. For example, the oldest task has been there for 3 years.

We are mostly running on urgent customer demands or important bugs. Developers complain that there isn't enough time to eliminate some work from the backlog as they are mostly concerned with urgent tasks. Also there are some stall works which are tasks that our team cannot figure out how to handle and these tasks are everywhere -backlog, development, and even in review. Tasks get stuck in review phase because some of them take long time to simulate or test so the developers are not willing to go through the testing phase because they prefer working on urgent tasks.

There isn't a limit in WIP because they say they are constantly interrupted by unplanned or urgent tasks and that it would be pointless to limit WIP. So I am unable to limit the number of tasks developers work on.

I don't think the developer team is undersized, I just think that they lack a system and they like to work things out in their own way. The work I have done so far is about filtering the customer requirements so that the backlog wouldn't have any redundant tasks but the old tasks are still there.

What can I offer the team so that they can deal with both urgent tasks and stall tasks?

2

First: It's clear that your testing team is way too small. A ratio of 5:1 is simply going to (1) cause a huge backlog and (2) cause bugs to slip through. Your own project is proof of this.

Even if you could prove that your 5:1 ratio is sufficient you need at least one more tester. A team of 1 tester is not a good idea because you don't have anybody testing the tester. As you yourself wrote you have a constant list of important bugs! QED.

Second: Your team is wasting a lot of time with juggling the list. And some of this list is simply never going to be done. You cannot see the forest for the trees!

My suggestion is to take off an afternoon and play kill the list.

Spend the first half hour setting the rules (that you should prepare beforehand, but you want 80% buy-in to retain your sanity.)

A few rules you may want to start with:

  • Any item older than (x months) will be moved to a category called too old and we'll look at it again if we ever run out of work.
    • Any time any ticket in the future hits the expiry date, it gets added to the too old list without further ado.
    • Why? Because if the customer has managed to live with it for (x months) then they'll probably survive a while longer. Besides it's not being done anyway, it's simply wasting our time to review continuously.
  • Any item that nobody has a clue how to solve goes into the mystery category.
    • Maybe hire a hacker to tackle these mysteries of they seem important.
    • Maybe have a hackathon weekend with prizes for solving these mysteries.
    • Either way, get them out the way. If they are (also) bugs, mark them as know issues, and add it to the documentation.
      • A standard joke is that a bug can be turned into a feature simply by documenting it. Funny or not, use that approach meanwhile.
  • Divide all other work into 3 categories:
    • Quickies: stuff that will take an hour to fix.
      • These can be done at the end of the day, or the end of the week when nobody feels like tackling a big feature, or during a weekly/monthly "Whack a ticket" period where the one to fix the most of these gets a prize.
    • Big Bugs: the stuff that will take longer than an hour
    • Customer requests / features
      • Everybody needs to alternate between them; one Bug, then one Customer then a Bug, etc. This way you get to some equilibrium.

The aim of this is to get the list small enough that everybody can see what they are going to be doing in the foreseeable future. They will stop wasting their time reviewing stuff that they will never get to do.

Last: You don't think the developer team is undersized. But if you read your post again, it's hard to believe. I don't see how even the slickest system in the world could shrink a 3+ year backlog - that is being fed constantly - without adding manpower.

0

There are a couple of problems here.

The first problem is the large backlog. This is relatively easy to solve - review the items in the backlog and resolve anything that is no longer necessary. Resolution could be anything from deleting the items to marking them as "won't do" or "obsolete". Removing duplicates can also be done at this time. This smaller backlog should be easier to prioritize and generally manage going forward. I would caution removing known issues from the backlog - it's feasible that customers or potential customers may request to have access to known issues or a relevant subset of known issues.

The second problem is the lack of WIP limits. I would recommend instantiating these. However, since you are also working on critical issues, having an "expedite" row on the Kanban board. I would also recommend starting to gather metrics around throughput and cycle time so you can start to predict future work or when you can possibly start and finish work based on where it is in the backlog. I believe that one of the things that these metrics will reveal is that you need additional people or a change in process that allows you to move work from the ready for testing time through to done faster.

The third problem appears to be around the number of critical issues. Having large number of critical issues that cannot wait or need to be expedited could indicate poor quality. It could also indicate poor product management and prioritization of these issues. Going back to having metrics, if you have data on how long it will take work to be done given a placement in the backlog, you can work with stakeholders to determine if work really needs to be expedited or if it can be prioritized appropriately and follow your WIP limits. In general, reducing the number of defect fixing work being added to the backlog would also be beneficial to the team and project.

0

We have a really large backlog, it is full of tasks that are almost forgotten and it does not seem to get any better. For example, the oldest task has been there for 3 years.

One approach I have used in the past is as follows:

  • Work out roughly how long it takes on average for a task to get completed (using historical data).
  • Work out roughly the rate at which 'urgent' items are added to the backlog.
  • Then, calculate how far down the backlog the team can realistically get in 6 months.
  • Finally, speak with the people who requested items that will take at least 6 months to get completed, telling them that these items will be archived if they don't respond saying they are OK waiting this long.

I find this approach tends to focus minds. What often happens is either the people requesting the work agree to archive the tasks or they push for more resources for your team so that the tasks will get done sooner.

There isn't a limit in WIP because they say they are constantly interrupted by unplanned or urgent tasks and that it would be pointless to limit WIP.

This is a situation where WIP works really well!

When an urgent or unplanned task appears then the team looks to see if it will cause the WIP limit to be exceeded. If it does then something else needs to be withdrawn from that queue.

For example, an urgent bug fix comes in. The team already has 5 items in the 'development' column, which is the WIP limit. They look down the list and and remove one item, putting it back in to waiting to start column.

Next the team informs the person that requested the item that just got returned to the waiting to start column. They tell them that their work will be delayed due to a higher priority task.

The benefits of this approach are:

  • The team has clarity on what work they need to do as there is reduced clutter
  • Expectations for when things will get completed are realistic
  • People requesting tasks will quickly grow to understand the impact of unplanned tasks upsetting the flow of work

Finally, you may find it valuable to try and quantify the impact of the urgent and unplanned tasks.

For example, you could put out a fortnightly status email saying things like:

Due to the urgent fixes to the database that came in last week we had to halt work on several tasks. The team took almost a day to switch across to the new tasks and that time is effectively lost. We would estimate that the impact on the team was a reduction in efficiency of 10-20% over the course of the fortnight.

Again, this will help to focus minds.

0

The fact that your oldest note (task) is three years is not necessarily a problem, simply because no matter how big a team you have they together with your customers will always be able to generate more ideas on new things to develop/change/refactor/fix/etc than what your team's capacity will be able to manage. If this is understood by the team members they will have less of a problem with an ever increasing backlog. However you might want to spend a day or two per year to clean it up; simply by going through the older items and get rid of the ones that no longer would create value.

The benefits of using WIP limits are very well described https://leankit.com/learn/kanban/benefits-of-wip-limits/ in my opinion.

However your question was on how to manage both urgent and stalled tasks, let me try to elaborate a bit on how we manage it in our development, which is working quite well.

First of all I believe you might consider changing the content of your notes. You mentioned that you have notes containing tasks. In our development model we are trying to make sure each note is describing a deliverable that will add value to the product. To complete that deliverable (note), a lot of different tasks may have to be undertaken (requirements analysis, architectural choices, design, implementation, documentation, verification, validation etc). When working with WIP limits, we have seen that it becomes more effective if you use deliverables instead of tasks. We have two different WIP limits. One for the notes on the entire board (not including notes in the backlog or the done columns), we call this the Kanboard WIP Limit (KWL). The other one is the WIP limit for the individual phases on the Kanboard, we call this Phase WIP Limit (PWL). KWL = team size - 1 PWL <= KWL On top of this we have also said that the PWL should decrease as we move from right to left on the Kanboard.

An example: If your Kanboard has the phases Requirements and Design (RAD), Development and Component Test (DCT), Feature Test (FTE) and Integration Test (ITE), while your team size is 4. KWL would be 3 (team size - 1) and PWL <= 3. PWL starts from one in the rightmost column and increases by one up to a max of 3 in this case.

  • RAD has a PWL of 3
  • DCT has a PWL of 3
  • FTE has a PWL of 2
  • ITE has a PWL of 1

We try to keep the estimated effort for a note in the backlog to maximum of what can be completed within 2 man weeks. Since the number of notes in progress are limited by the WIP limit, this means that more than one person will work on at least on one of the notes; promoting team work. With the PWLs decreasing over the board, it also supports the core idea with Kanban to support flow (getting things ready for release) instead of keeping many things in progress (or stalled) at the same time. If a note is stuck in the ITE column, then no other note may move there. This emphasizes even more on that it is more important for the team to jointly finish off the remaining tasks to get that note done instead of starting something new. With the estimated deliverables are of at most 2 man weeks, we believe that they are broken down well enough to support that all persons in the team will be able to understand what is to be done to get the note to the "ready for release" column. When deliverables in the backlog are bigger than that, too much time tend to be spent on doing things that are not necessary or things get missed simply because what to deliver is not clear enough.

Lets say there is an item stalled in the ITE column and only 3 out of the four people in the team can contribute to working on it, then the fourth person should work on the top-most note in the FTE column (highest priority at the top in each column, just as in the backlog). Maybe that fourth person cannot contribute (easily) to the FTE note or the DCT note or the RAD note for that matter. In that case slack has occurred (slack in the sence of what is described in the link above).

Stalled notes need to be managed by the team or team managers just as any other note. If something is hindering the team to continue working on it, then a manager/product manager/project manager/scrum master/agile master (or whatever you have at your place) needs to assist in solving the hinderance. If this is something that does not involve the team members, then the note should be put back into the backlog again (because nobody in the team is actively working on it).

Urgent tasks as you say may very well be tasks (not necessarily deliverables). It could be "investigate this bug report" or "measure this" or "summarize this for a customer", "a bug that prevents the team from working needs to be solved" etc. For these, we have introduced an ambulance (just one) on our Kanboard. Such an urgent note is accompanied by the ambulance as it moves over the board and the ambulance is the only item that is allowed to break the WIP limit. When the ambulance is on the board, it takes priority over the other notes and as many as possible from the team should contribute to remedy the urgent note as quickly as possible.

If you use this setup and find yourself in a situation where the ambulance is always (or very often) present on the Kanboard then you may have to consider setting up a single specific team to manage only the ambulance notes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.