nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Scrum vs. Kanban - Why not the best of both worlds? (Agile / JIRA Rapid Boards)

mcwumbly

Scrum vs. Kanban - Why not the best of both worlds?

Our software development team has been experimenting and refining our process for managing the development process over the past 12 months. Throughout this time, I've also been evaluating several tools for helping manage the process. Overall, we're pretty happy with JIRA and its rapid boards.

We sell our products to customers and use them ourselves. Our industry requires rapid response, so while we are not developing web based SaaS products, we still must release almost continuously.

Thus, in practice, we operate in a fashion more closely described as Kanban than Scrum. We can't time box sprints and release on a regular schedule. The priorities change too frequent and we often have to release sooner than later.

However, I've found that the Scrum board in JIRA is better suited for us than the Kanban for one reason: Plan mode

Without plan mode, the kanban board gets too crowded with the entire backlog. Plan allows us to separate cleanly what ideas and issues should be done sooner and which ones shouldn't. Keeping them off the work board let's the developers focus on what is important.

OK, so I've found my solution, what's the problem?

The Scrum board forces us to artificially box things up into 'sprints'. Since we don't really have sprints, the closest thing is to create 1 sprint for each release, whenever that may be. But that means the work board has to be torn down and re-built after each release.

With the Kanban board, on the other hand, I can clear the 'Done' column each time we push a release out just by clicking the link at the top of the column. Other work can continue without disruption.

If we had Plan Mode on the Kanban boards, it'd be close to perfect

So why is it greyed out?

I can only assume it has something to do with either a rigid interpretation of Kanban, or some implementation detail under the hood.

Regardless, for our style of working, it'd be a tremendous improvement.

Hope it finds it into some future release!

Anyone else out there on a team the works in a similar fashion?

Would love to hear if you think Plan mode on the JIRA Kanban boards would be helpful - or if you have used any other tool that you find to be a better fit...

Comments

Eugene

Yes. Have the same requirement.

Roland Palmqvis

Me to. We are just in the process of moving to Jira and as a PM I need to to have items in the future plans that are currently not on the canban backlog.

Surely there must be a way to do both long term planning and using Canban as the flow control in RnD without the need for spreadsheets (or I'll be DISAPOINTED!!!)

Norbert Schultz

Small teams here would really like this, because Scrum is too massive for small projects.

mcwumbly

It's been working pretty well for us to just use the Scrum configuration and add items to the Sprint mid-sprint (even though you get the 'Hey, you're changing the scope of this sprint finger wagging warning').

Its a little annoying when adding new issues that there's not an easy way to add them to the current sprint from the Create screen (or maybe I just haven't figured out how to set that yet).

Still would like to see the ability to use Plan mode in Kanban though as the above always feels like a workaround

John Burk

This pretty much summarizes our current usage patterns. We're a very small shop, and our dev's also do customer-facing support as well as bug fixes, so we're very much interrupt-driven. Some bugs can take long enough to repro/troubleshoot/fix that they would cause us to fail sprints, and some weeks are more support-heavy than others.

For this reason, we can't really do timed sprints, but we do have a minimal feature set for each version we need to meet in order to release. The Kanban boards have been perfect for our needs.

But we also need this planning feature, since we continually move features between unreleased versions to manage our product roadmap several major and minor versions into the future.

Brendan Martens3

I had the same issue with the Kanban board getting crowded; my solution was to create two boards with the same filter (generally) but with different colums and each use different statuses.

Our "planning" Kanban board has 3 columns, backlog (mapped to a new status I made called backlog), ready for development (mapped to todo), and ready for release (mapped to done). This view lets us have a large backlog and do planning on the top issues in the backlog to prepare them for the developers, while also seeing a big picture of items in backlog through ready for release. I intentionally left the "doing" or "wip" column out of this board because managers are not allowed to change something that a developer is actively working on.

The "work" Kanban board is the one we look at every day. This board has the same "ready for development" column as the planning board so that when something is transitioned in the planning board it is automatically updated on the work board as well. The next column on the work board is our "doing" column, or "wip". This is matched to the "in progress" status. Then we have a reviewing column that matches to a new status I created called "reviewing". Lastly, this work board also has the "ready for release" column that the plan board has which makes it easier for reviewers to transition items.

So far this has worked quite well for us by helping keep the board developers use everyday from getting cluttered, but not requiring project managers to keep the backlog to a minimum (which would defeat the purpose of a backlog!)

All that being said, I am still looking for a way to make the presentation of the backlog easier to parse at a glance. The Kanban cards are quite tall compared to the scrum planning mode cards. I really miss that presentation for the sake of prioritization.

Dan Wyks

The DevOps team I am the coach has the same problem. After recently upgrading Greenhopper to 6.1.1 we switched from Scrum to Kanban. I was disappointed that Kanban Rapid Boards don't support Plan mode. I didn't want the daily Kanban board cluttered with backlog so I created a Scrum board for the backlog. Our daily Kanban board excludes the backlog status which keeps the team focused on WIP. We don't use any of the Sprint related features of the Scrum board, but we do use Epics.

This approach is working well so far. I recommend trying it.

mcwumbly

There's no best answer here, IMHO, only workarounds. But this looks like a good one

mcwumbly

There's no best answer here, IMHO, only workarounds. But this looks like a good one too.

Iain Forrest

There are a few people trying to get this option added. Please add your support by voting for this feature here

https://jira.atlassian.com/browse/GHS-6175

Ronald Horner

We used 2 boards for a while also and all it did was confuse our Product Owner and even worse, confused our enterprise software manager (who has at least 12 teams he oversees). We switched to the solution posed in the OP.

Ziad El-Dajani

This would make a massive difference. I've been testing out using a Scrum board for planning and Kanban for work but for some reason the same tickets do not appear in each backlog.

Dan Wyks

First thing I would check is that the filters you are using for the two boards are the same or at least that the backlog's Scrum board filter is less restrictive than the Kanban board's filter.

After that I would check that backlog Scrum board's filter maps all of the statuses used on the Kanban board to columns. In addition the Scrum board should have at least one additional status that the Kanban board does not. This "extra" status identifies the item as a backlog item and is not represented on the Kanban board.

Ultimately, the Kanban board should be a subset of the Scrum board that shows only the items that are ready to be worked or are in progress.

Hope that helps.

David Crebbin

"I didn't want the daily Kanban board cluttered with backlog"

Have I missed something?

Why don't you have a simplified Workflow on the Kanban Board, and create a 'Queue' column for you left most column with the special status 'Queue'. Here you place any items you want in your queue and the Kanban board in green hopper is un cluttered. You can search for issues in standard JIRA and put their status from 'Open' to 'Queue' to place them in the queue, at which point the item has entered the system and you can start tracking against this.

Ronald Horner

The goal is to manage the Kanban backlog from inside Greenhopper. This is done by using the Plan mode which is only available to Scrum. We would like this available for Kanban so that we can manage the backlog and WIP in one location. Your proposed solution is still managing the backlog outside of Greenhopper.

Dan Wyks

@david Our 'To Do' column is the left most column on our board and represents the backlog items we are ready to work on; those that have entered our system and are being tracked. I did not want the other backlog items in any column on our Kanban board because we are not ready to work on them and I have a WIP limit on 'To Do'.

I'm not sure how your 'Queue' column is excluded from the board in Greenhopper. Is it just a status without a column? What you suggest is effectively what we are doing. I have a 'Ready to Pull' status that maps to the 'To Do' column of our Kanban board. When an item enters our system it is set to 'Ready to Pull'. I use a Scrum board to manage the backlog because I want to associate stories to epics and rank order the stories in our backlog. The Scrum board makes those tasks easy.

Jay33

Has any of this been improved with subsequent releases? I'm still planning our conversion to Agile but understand conceptually the problems while reading through this. Still playing the scrum v kanban game in my head for our software development.

Brendan Martens3

As far as I know everything is about the same. You can still implement one of the workarounds mentioend on this thread, but if your question is "is there a plan mode for kanban in Jira Agile", then the answer is no.

As previously linked in this thread, you can follow this ticket if you like, but so far it hasn't changed anything either.

https://jira.atlassian.com/browse/GHS-6175

Gregory Demotch

Great discussions here.

My fervent wish is that JiraAgile, actually delivers a 3rd type - PureAgile.

Scrum is super restrictive, if you are not scrum and you use it, then you are stuck with fighting the despotic Scrum logic every day - and hitting a brick wall against people saying what scrum is and what scrum isn't.

Kanban is a great solution for multiple teams, and in fact it's great to use in combination with Scrumboard. But Kanban by itself is not appropriate for long-term development - no planning mode.

So guys, what we really need is another PureAgile Board, a configurable board with Planning, Iterations instead of sprints, to plan the roadmap, not just groom the backlog. and make it as configurable as possible which will the end the endless discussions on what should happen to issues when sprints/iterations are finished, etc etc.

And hey, we need all kind of time estimates, not just dev estimates, but Test estimates to be shown on the board, especially when the card hits the resolved column

Mike Thomas6

Here is a possible workaround I've come up with for myself (but I haven't really put it in action yet). I'm not advertising it as awesome, but might be useful to others. You have to be willing to put aside an issue type and use a swimlane for your backlog.

Identify an attribute you are willing to set aside for the special purpose of reserving items for your backlog. I chose issue type, and specifically the "New Feature" issue type. Now, set up swimlanes so these special issues have their own swimlane. This is a little tricky, because we want this to be the bottommost swimlane. Atlassian, for God knows what reason has made it so that the "Everything Else" swimlane HAS to be on the bottom. So we need our special issues to end up in "Everything Else" so they fall to the bottom of the page.

To achieve this, I created a new swimlane called "Main Flow", and in it I "New Features":

issuetype != "New Feature"

This forces my "New Features" to fall into "Everything Else", which becomes the backlog or however you like to think of it.

Mike Thomas6

Arrgh! It should be obvious, but I meant to mention that obviously, when you want to move an item from the "backlog" to your main flow, you change the issue type to the real type. Then the issue will move to the right swimlane.

Daniel_3ufwci

My last dev team went this route as well. It worked very well for us. For the first few months, I didn't even realize the Plan view we used wasn't part of the Kanban set up.

Joseph Cheek

The problem, IMHO, is that having a Backlog column in KB makes the page very very very tall and difficult to see at a glance, since you only see one ticket side by side, regardless of the width of your browser window. I quickly realized that I would need another column, To Do, to separate Backlog (To Do Eventually) from To Do (To Do Soon), which is of course different than In Dev (In Progress/Doing Now).

Great, but Backlog still gets crazy tall. Sprints would be great; I could remove stuff from Backlog without worrying that it would be Gone Almost Forever, because Out of Sight is Out of Mind.

What I really want, giving me a manageable Backlog, would be a 'postpone for three weeks' issue state. I know I'm not going to get to this ticket in the next three weeks, but I don't want to think that I have put this ticket in a state where it will be completely forgotten. Transitioning a ticket to this state will take it off my KB board for three weeks, at which point it will reappear in my Backlog. Long enough for me to clean out my Backlog, but not long enough to keep it from disappearing from my memory, or causing me to worry that it might disappear from my memory.

I'm pretty sure that I can do this with a combination of some filtering and some special ticket field, and some workflow or scripting trickery that assigns the particular field to "today's date + three weeks". I don't know the details, but it seems like this should be doable with a fairly-standardish Jira installation.

I hope it works. Wish me luck!

Dan Wyks

Joseph - I just did a quick test and you can use standard JQL to do the date-driven filtering you described. For instance, I achieved what you described by using the Due date field on a story and adding "AND (due <= startOfDay(45d) OR due IS EMPTY) " to the filter used by my Kanban board. You could also use the same JQL as the basis of a Quick Filter to make it easy to turn the filtering on and off.

Dan

Joseph Cheek

Great! Any idea how to create a button or workflow status that will automatically add 21 days to the due date? the only triggers i can see send emails out, not change field contents.

mcwumbly

For what its worth, about a 18 months ago, we switched to using Trello for our Kanban / planning boards. We modeled our process based on the ideas presented here, with a few minor tweaks.

https://community.uservoice.com/blog/trello-google-docs-product-management/

It has worked out quite well for us, and encouraged wider adoption among the non-devs within our company, because they have found use for Trello to manage their own tasks.

Still a fan of what Atlassian does - we use HipChat and BitBucket on a daily basis.

Mark Tomory

YES. Hear, hear.

Techex Support1

Completely agree with the above. Being able to change the height of the cards would be a start..

Total Care Auto

It's too bad that the "Plan" button has been greyed out for so long. We tried to migrate the development team away from PivotalTracker which added Epics last year but just can't get the same ease of use and flow for a team that continuously delivers. I believe that the plan feature with kahnban will be good enough to completely move off but for now Pivotal wins for us.

David Crebbin_qpfbf6

Not sure which account I used to post my first answer originally, but thought I'd update here.

Yes, I totally get what this original question was referring to now, and yes, not having a 'backlog/plan' mode is an oversight in my eyes.

Since boards are simply a view onto project(s) or however you want to form your JQL, I've found these days I setup JIRA as follows:

I have multiple different projects instances, depending on the amount of teams/projects I have to manage
Since most my projects have similar workflow/statuses, I have one Kanban board as an overview of all projects where it makes sense, using projects as the swim-lane.
If I need separate project boards with further swim-lanes I can create project specific Kanban boards.
I create a scrum board that I only use for backlog management.
I have "Backlog" status which comes before my "Queue" status. "Queue" moves this to the Kanban boards (similar to "To Do") and "Backlog" status makes it available to manage nicely in the scrum planning board.

That's just the way I do it.

Hope they introduce backlog functionality direct from Kanban boards so it's not such a messy workflow, but it's manageable

Johan Pretorius_tzcvkg

Thank goodness I'm not the first who is about to try this, I was quite worried that this would break things for us. But maybe I should give it a try, given that some have found it quite seamless.

Mike Socha III

I agree, I love the scrum board's backlog's ability to reorder and rank issues, and the unrestrictive free-flowing format of the kanban board! I wish the kanban board had a similar backlog board for re-ranking issues just like the scrum board!

Rama Pokala

Good to understand how the world been using these boards, rather assuming that everyone using them same way as we did !!! We are using the "Plan Mode" as Agile Rapid Boards in JIRA that is used for defined and approved Releases & Sprints. Where as Kanban Board been used for tracking operational tasks which doesnt fall within a certain time-box. We defined a label and used a filter to drive the backlog items to get into Kanban board across various applications/projects. Also, we use Kanban board for prioritizing and tracking the initiative at the organization level, similar to portfolio management. I hope someone using these boards they way we are using, Am I wrong?

Just Vervaart

http://blogs.atlassian.com/2016/03/kanban-backlog-jira-software/

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-cloud

agile

board

kanban

scrum

plan