Kanban methodology

[Larry Zhang]

Hi, I have been using Scrum methodology where I define epic, subepic, features, and then user stories. We also do big planning every 3.5 months, and for these 3.5 months, we plan all the user stories for this time, and we use a release for this 3.5-month work. We group user stories logically to feature and plan all the features to be done in these 3.5 months,  we call this a release. So far so good.

However, the team now prefers to use the Kanban methodology. As the Product Manager, I respect the team's preference and I started to organize the user stories on the Kanban board. Now several questions show up: do we still need to have Epic, Suepic, features, and user stories? We seemed to agree that let's still have these, but would like to hear the SME from Rally on this.

Another question is do we still need to have the release concept, i.e. treat each 3.5 month work a release? If I continue to use the release concept, and then assign each feature to the release, and then assign the user story to the feature, and then these user stories show up on the Kanban board without issue.  The downside of this is when I create a new user story I have to remember to assign it a release, otherwise, this user story will not show up on the Kanban board.  So you can see I face a conflict. Is there a way to make my user story show up on Kanban without using a release concept (it is a best practice to continue using the release concept), I would like to hear the SME's guidance. Thanks.

[Nick Wallis]

Hi Larry, 

Thanks for putting yourself out there with a great question for the community!

In using Kanban or Scrum, or both, I think it's best to consider what you're trying to do at what level. At the squad layer Scrum is useful to timebox the work the squad needs to do, which helps drive predictable work practices over time, estimate work, and drive improvement. In my experience, Kanban is useful at portfolio layers to help us understand blockages in the delivery framework, prioritisation, accountability, WIP limits, and cycle times (to name a few). 

For your queries: 

1. Epic, Suepic, features, and user stories? - This will depend on how you have defined your heirarchy. My guess is you'll still need Epics, Features & Stories, but that's hard to know without understanding your organisation & how you get value to your customers.
2. Do we still need to have the release concept? Releases are going to help you run Epic/Feature deployment (if you're still running Scrum ie. sprints at the squad layer) & integrate with external dependencies. My advice is to keep these but consider doing your big planning every 3 months (ie. 90 days) to fit nicely into your financial/calendar year.
3. Stories not showing on Kanban - When you create a story are you creating the stories under the Feature that is assigned to the Release? If you're not, then yes you will need to manually assign. To show full transparency of the the work being done to customer/colleague value we need to be able to show the connection to prioritisation. This is done by the parent (ie. Epic is a parent to Feature, Feature is a parent to stories). Without this relationship then we're just doing work without considering what should be done when, and most importantly why.