RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Agile Techniques: Getting Started With Kanban : Page 2

This guide is intended to help software development teams start using Kanban within their organization.


Groom the backlog

To groom this backlog, use criteria like submitted date and see how long that request has been in the system. Check with Product Owners as to values of keeping that in the backlog. Or implement a rule that says that all stories not worked on for 6 months will expire. To get it back in the backlog, the Product Owner will need to submit that request again.

Also, make sure that the backlog is properly estimated. Kanban does not require something like story points in estimates. Depending on the maturity of your team, you may need to use estimation until you feel that the stories are written in a consistent manner that the size is usually the same. This would get rid of the need for estimation.

Most teams will need to estimate what is in the backlog. This can be done using traditional XP/Scrum estimation with Fibonacci sequences, or use T-Shirt sizes. Sizing things at small, medium, large can eliminate a lot of wasted time in story estimation meetings.

When the backlog is ready, the stakeholders can put anything not prioritized in a Parking Lot area. The stakeholders can then prioritize those stories in the Parking Lot. When a story is pulled from the Backlog queue on the Kanban Board, it can be immediately filled from the highest priority story in the Parking Lot. This allows the team to always have stories that can move through the board, and the team is always working on the highest priority.

Set up Necessary Team Meetings

Daily Standup

Most teams using Kanban boards use the Daily Standup, common to most agile methods. The difference for a Kanban can be that large teams can use this concept. For smaller teams, the tradition of team members relating what they worked on yesterday, what they are working on today, and relating any impediments will work.

For larger teams, this may be impossible to keep a meeting to 15 minutes. In that case, the team only asks that the team members who have impediments discuss what those issues are. This helps keep the time in that meeting down to a reasonable level.

Stakeholder Planning Meeting

Since Kanban does not use time boxed iterations for planning, there needs to be a regular planning meeting to allow stakeholders to prioritize stories in the backlog. Also, there needs to be a regular release plan.

Assuming the team plans to release every two weeks, then any feature that is in the done column will be included in this release. Because this is based on a flow of stories going through the teams Kanban board, the team should be able to offer the business a predictable rate for stories placed in the board to get into production. Perhaps the rate is every month, or every two weeks.

The great thing about this rate is that it is based on facts from your board, not from estimates. This allows teams to set up service agreements with the business to give them a comfort in when their features will be deployed. There is much value to business in predictability.

Watch your team perform, and improve the process

Once you have started your Kanban board, you are not done. The entire idea behind Lean is that the team will continually improve processes to improve quality and delivery. As your product improves, this should impact the bottom line of your company. In the end this is all about making organizations deliver better products! Below are more resources to read up further on. If you are considering doing this, consider hiring a coach to guide you through this process.

Eric Landes is a Project Manager/Project Lead for a large corporate IT department, specializing in coaching Agile teams. He has more than four years of experience using Agile/Lean techniques to bring customer value and a team focus to projects.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date