1

Our kanban board has a familiar form: Backlog > analysis > QA/Dev Review > Ready to go > in Dev ... etc.

A topic of discussion found within the team (and across the company) is when should stories be pulled into the analysis column.

The clock on our cycle time starts when we pull into the analysis column and it is the first column represented on our physical board.

It's common that much of the analysis work is done by the product team in the backlog. Whether gathering requirements or researching in order to prioritise. By the time the story is written and gets to the board, there is often little or no analysis left to be done.

There is the view that all work should be captured on the board, and that the analysis time is the reality of the situation, but the reality is also that a product manager may be working on any number of stories in various states of readiness. For example you might have a workshop for something which may or may not turn into a story a month later. Stories may also be deemed lower priority than others and go into the backlog once the full analysis has been done.

Currently we're debating whether or not the analysis column has value and perhaps it should be stripped out. There would still be dev & QA review.

When is it best to pull a card into the analysis column and what work is typically done there?

Improve this question
2
  • "Pull into" implies that there's another column (or other holding area, like a Product Backlog) where stories exist before going into the 'analysis' column... but there's nothing in your Question showing that. Am I misunderstanding something?
    – Sarov
    Commented Jan 7, 2019 at 14:37
  • Third paragraph does state that there is a backlog, but I'll add that to the first paragraph for clarity.
    – Frankie
    Commented Jan 7, 2019 at 15:09

5 Answers 5

Reset to default
1

To my view, Backlog and analysis are redundant. However! You might want to add a different, 'Ready' or 'Analyzed' column. If you remove the analysis column, then it might be tough to tell which stories are ready:

  1. Conceive of work. Put into Backlog.
  2. Analyze work... Keep it in the Backlog. May or may not cause confusion - see below.
  3. Start review. Move it into 'Dev/QA Review'.

If your Backlog is ordered (with the topmost stories being fully analyzed), then it's fine. That's what my Team did for Scrum. Once we lost the Product Owner ordering the Backlog and moved to Kanban, though, we added a 'Ready' column:

  1. Conceive of work. Put into Backlog.
  2. Analyze work... Move it to 'Ready for Review'.
  3. Start review. Move it into 'Dev/QA Review'.
Improve this answer
4
  • That's quite similar to how we work at the moment, but it's capturing that analysis work that has me stumped. When the analysis is done in the backlog, there's no measure of the difference between time spent just sitting there in backlog and time actually being analysed. At present we accept that our board measures the time for a completed story to go from ready-to-go to done. But that means we're not tracking the product managers' work.
    – Frankie
    Commented Jan 8, 2019 at 13:52
  • @Frankie Do you not have 'Date created' stored for the story? 'Date put into Ready for Review' - 'Date created' = 'Time spent in analysis'.
    – Sarov
    Commented Jan 8, 2019 at 14:23
  • We have date created and analytics on all the columns. Sometimes we may have finished analysis on a story, but it is sitting in the backlog. It's no longer being worked on but after analysis we've found it to be of lower priority than another story, so it doesn't get pushed on, it waits in the backlog, waiting to be pulled, for example.
    – Frankie
    Commented Jan 9, 2019 at 15:44
  • @Frankie Then I would suggest adding it to the board, and just making sure to use priority on the board - higher priorities at the top.
    – Sarov
    Commented Jan 9, 2019 at 15:57
1

TL;DR

In your specific case, you should probably begin thinking of analysis as a queue with work-in-progress (WIP) limits and finite capacity. Analyzing faster than work can be pulled into the next step in the process is generally an agile anti-pattern, where just-in-time (JIT) planning and embracing change are core principles.

If you decide you must queue in a way that exceeds the capacity of the rest of your process, then you should either define a separate Kanban for that workflow, or break your current workflow into smaller steps that can be visualized and pulled from within your current board.

Pull Work Only When It's Ready to be Acted Upon

Kanban is a pull-queued system. This means that work must:

  1. Be pulled into a column by the person doing the work. It is never pushed there be anyone or anything else in your process. NB: Even a "Done" column is conceptually a pull, where someone is taking an action to mark work complete.
  2. The pull should only happen when there is available capacity, e.g. both the column and the board are within their defined work-in-progress (WIP) limits.

So, in your example, the analyst (or whoever will be doing the analysis) pulls work from Backlog -> Analysis whenever that person has capacity and is ready to queue or perform the work. I recommend only pulling the task when it's ready to be acted upon so that it's actually work in progress, rather than simply queued up.

Kanban does allow for the notion of queues, but the queueing column should never exceed WIP limits. If you find the team pulling (or worse, pushing) work into a column that is routinely blocking, you'll need to review your process and your WIP limits to determine how to optimize your flow better.

Queueing the Analysis

It's certainly possible to design a Kanban process that has multiple flows, with multiple input and output queues, but this isn't really your use case. Instead, you should acknowledge that you can only analyze a certain amount of work at a time, and define your WIP limits and processes around that fact.

However, visualization is important, too. If you really want to queue work that needs to be analyzed (e.g. queued separately from the backlog), you might consider sub-columns. For example:

BACKLOG |                      ANALYSIS                        | QA/DEV REVIEW
  ...   |  Queued for Analysis | Analyzing | Analysis Complete |      ...

In this case, you can visualize how much work is queued, how much work is actively in progress, and what's available for the QA and Development teams to pull into their columns. Just keep in mind that it's still conceptually a pull queue: the analysts pull the work into the queue, and through their own task columns; the developers pull only from "Analysis Complete" when they have capacity.

If you go this route, you will also need to ensure that the WIP limits for "Analysis" as a whole, and each sub-column within it, have sensible individual and collective limits. Within a single Kanban process, there's very little point in pulling 10,000 items into "Queued for Analysis" if you're trying to measure cycle time from Backlog -> Release, or having more work in "Analysis Complete" than can reasonably be expected to be done within your cycle time or iteration. That's why the WIP limit for the whole board should be adhered to, in addition to any column-level limits: Kanban requires optimization for flow by reducing queue length and batch size, so you violate those principles at your own risk.

Improve this answer
0

In fact, it is critical to understand - and improve - whatever is done during the “analysis” that is done while items are still sitting in the backlog.

As you said, the product management folks are working on a number of things and their work load/ workflow needs to be understood as well.

It is not just important to cover your dev team activity in the Kanban board. Ensuring that sufficient work has been done on new features/ user stories, that there’s enough detail from functional, non-functional, UI and UX aspects, etc. is critical as well. Every time you pull new work into your Dev team’s Kanban board, ensuring you are pulling the right things which reflect the business priorities of your customer or your company is important.

The subject of Upstream or Customer Kanban covers all of this. You could do 2 things - either expand the Backlog column into sub-columns or create a new “upstream” Kanban board (or an Upstream lane in the same board) which reflects the process of identification, detailing, discussion, analysis, functional specification, UI/ UX design, prioritization and scheduling work that happens - or needs to happen - before selecting something for development. You can call it the Product Owner/ Management board or lane.

In your current board, which is clearly the Dev board, you can then drop the Backlog and Analysis columns and instead simply have a Ready column where new items prioritized in the PM board show up at whatever cadence you follow for replishing your Dev team/ board.

Besides helping you identifying the process that is already happening in order to produce work for your Dev team, this Upstream board helps you better collaborate with your stakeholders and help them prioritize the right things at the right time. That is crucial for your business overall.

Improve this answer
0

Just before you start analysis on it. But this isn't a question about Kanban itself, it is a question about the process you are applying Kanban to, so you are much better able to answer the question than us. (The question you are really asking is how much Analysis should we do before the lead time timer starts / we commit to starting work i.e. Backlog Refinement, vs how much should be done after this commitment point i.e. Analysis proper- I always prefer Backlog Refinement to be a mechanical activity focused on splitting and estimating the what to build, and Analysis proper (creative work focused on how to build) after this commitment point). You will probably get better true end-to-end lead time statistics by preferring to do less analysis in the backlog, and more after the commitment point.

Improve this answer
-1

From my perspective: you can put whatever columns make sense for you and the way you work. But I've also found that keeping it simple is much better - starting with fewer columns and building up when really, really necessary. The simplest being:

  • To Do
  • In Progress
  • Ready To Test
  • Done

From that point on, you can decide whether you need extra things like, Ready for Development (aka Refined), Ready to Merge (if merging the code requires extra checks), etc. If you feel something is not needed and just takes the extra admin effort to move all tickets in that column, I think you should remove it.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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