4

Facing a kanban board workflow issue and don't think we've quite nailed a solution yet.

We're building an app backed by a middleware tier serving up JSON content. Nothing new about it.

Issue we have is maintaining a solid workflow.

At the moment we have the following (of relevance) columns: Ready 4 Dev | In Dev | Ready 4 Test | In Test

We ALSO have horizontal swimlanes for iOS | Android | Server cutting across each of those columns.

We ALSO have colour coded tickets (red = bug, purple = server etc).

Ideally, in a sequential world, we'd have columns for f/e and b/e, but needless to say, work can happen on components in parallel.

Several ideas we've had:

  1. Use ONE ticket/card/story that sits in an "in flight" lane while it's composite tasks flow across. It's only completed once all tasks have completed

  2. A STORE is broken down into TWO (or maybe more) tickets (basically tasks) abut we remove the horizontal component (b/e and f/e) swimlanes

EXAMPLE:

Feature: T&Cs (as part of an MVP)

Ticket 1: Format and style HTML docs Ticket 2: Upload HTML docs to server and provide addresses Ticket 3: Implement WebKit calls to HTML files Ticket 4: Middleware service to communicate between client and DB (to record when and what version T&Cs were agreed to on registration)

For example...

So there are many related tickets floating above that each need different people or teams working on them to complete a somewhat trivial feature.

Suggestions?

Improve this question
1

2 Answers 2

Reset to default
2

For visualisation purposes you can create a new lane on the top called "features" where you put your high level cards. When you are ready with the underlying cards, you move them to done.

Improve this answer
1
  • 1
    A feature lane works well, and it works even better if you have some visual link to its sub-tasks (a simple numbering scheme works).
    – Danny Schoemann
    Commented Feb 29, 2016 at 9:53
0

You didn't really give any details about the actual issue you are facing. Is it something like Android or iOS cards building up because they have to be done after the JSON bit? Or vice versa?

If my suspicion is correct, just have one card for the feature, and have a dev JSON column to the left (or right) of DEV Mobile. Something like that.

It is actually better I think to not force the order here though, but I am not sure what problems you are facing doing it in parallel.

Point 1 sounds confusing, tracking both stories and tasks on the same board. I have seen it used, but I think it is too complicated.

Perhaps you could have two boards. One higher level stories, and smaller ones featuring tasks for the teams to use.

Point 2 could be something, but once again, I would have to know more about the problem. I would really try and use story cards rather than task cards on the kanban board though.

Please give some more details about the problem, and maybe we can help better.

Improve this answer
10
  • Made some edits to my original and included an example..
    – Paul
    Commented Sep 16, 2015 at 8:25
  • I would say, just stick to one card per feature, and one column for stage in the workflow, and whoever works on it, depending on the column works on it. I am still not sure I can visualise the issue. We regularly have a similar situation and the simple approach works for us. Sorry I guess this is not that helpful. The only thing I am picturing is that your board is too complicated with task based cards, and I would suggest simplifying it and using feature based cards.
    – Kurt
    Commented Sep 16, 2015 at 13:12
  • 1
    I was forming the same questions as Kurt while reading the original question. :) It sounds like you are struggling with too much detail on the board - are there true benefits to tracking each task separately, vs. lanes per stage or collaborators coordinating "off-board" and moving the card together through stages?
    – Jeff Lindsey
    Commented Sep 16, 2015 at 15:30
  • How are you able to work on things in parallel? surely front end work is dependent on the back end being completed?
    – ashga
    Commented Sep 17, 2015 at 11:16
  • The very fact that we CAN work in parallel is part of the issue. So atm, we create TWO tickets for the same story/feature. For example "User can phone xxxx" - ONE ticket to implement the call button and ANOTHER to provide the number from the server in JSON. Both can happen in parallel (although both at a point are dependent on one another.
    – Paul
    Commented Sep 17, 2015 at 16:24

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.