Get hands-on training for JIRA Software, Confluence, and more at Atlassian Summit Europe. Register now ›

No matter what agile framework your team uses, Portfolio for JIRA can forecast a realistic roadmap for your product or project. In our blogs about Portfolio for JIRA, we’ve focused heavily on Scrum methodology, but lately we’ve been getting more questions about how kanban can be planned in Portfolio for JIRA. So lets see how you can setup and plan your kanban teams.

A background note: At the moment, Portfolio for JIRA doesn’t have a direct solution for kanban – but there’s a simple workaround! We have a team configuration for kanban, and while this is perfectly viable to plan your kanban team’s roadmap, it isn’t really faithful to the kanban practice. So we’ve put together this workaround so that you can calculate roadmaps for your kanban team. Keep in mind that with any agile process (particularly kanban) a certain level of long-term planning is sacrificed for the delivery of high-quality software. Requirements and business strategies tend to be revised over time which are likely to impact your plan. While Portfolio for JIRA is perfectly suited for adjusting your roadmap on the fly to accommodate new scenarios and changes, it’s up to your best judgment to balance roadmap commitments with what you know you can accomplish. Decide over time your highest value goals and what you’re pushing for, inform Portfolio of any revisions, and visualize changes in your plan’s roadmap. So with that piece of advice, let’s talk kanban!

But first, what is kanban?

Kanban is a leaner agile development methodology that loosely translates from Japanese as “card you can see.” Inspired by Toyota’s practice to meet their JIT (Just-In-Time) manufacturing process needs, this process wonderfully translates to continuous delivery of streamlined software projects. Kanban visualizes all work items as self-contained, relatively equal effort task “cards” on a board in a series of columns. Teams prioritize a list of work items in their “to-do” column and when they’re ready to start developing on a new item they simply move the the card into the “in progress column.”

As individual work items progress, they are advanced through workflow columns. In JIRA these columns are simply “Backlog,” “Selected for development,” “In progress,” and “Done” but they can be more granular to include more processes such as planning or quality assurance. Both scrum and kanban methodologies work well, so why follow kanban? Kanban is a much leaner agile methodology suited for teams with clearly defined work-to-be-done. There’s a greater focus on visibility, flexibility, and processing tasks that deliver incremental value, rather than managing team processes.


Portfolio for JIRA meets kanban

1. Create a project or board in JIRA Software

If you intend to start using kanban in JIRA Software from scratch, then first you’ll need to create a new project or board and select the option to setup a kanban board. It’s not absolutely necessary to use a kanban board (a project or filter would also work) but having a kanban board will ensure you have a consistent practice between Portfolio for JIRA and JIRA Software. If you’ve already got a board, project or filter ready then you can jump straight into Portfolio for JIRA.

2. Create a Portfolio plan

From the Portfolio for JIRA top-menu item select “Create a plan” to start the plan creation wizard – a super simple wizard available in Portfolio for JIRA 2.0 that will help you create a plan in less than a minute! Proceed through the steps: name your plan, select your issue sources and “Story points” as your estimate. Advance to the team page – selecting your releases on the way (if you’ve created any). On the page “Define your teams,” for this workaround, set your scrum iteration length to 1 week and set your velocity to your team’s throughput. If you don’t know your team’s throughput, that’s ok. I’ll explain how you can figure that out below and you can configure it later. Continue through the steps until you reach your plan.

What’s the deal with estimates in kanban? Unlike scrum or traditional development processes, kanban teams usually don’t estimate their work. Instead, kanban breaks down work into similar-sized tasks and uses cycle time to measure how many tasks can be done in a time-frame. This blog focuses closely on this concept of kanban, but since Portfolio requires estimates to schedule, we’ll represent them as equal-sized points. Then, using some simple math with average cycle time/lead time, you can build an accurate forecast. If you use a hybrid model of kanban with time based estimates then you can simply set your teams to “kanban” and schedule day-to-day based on team member weekly hours.

Don’t worry if you don’t see a schedule here – as using kanban you’re unlikely to have estimates on your tasks. If you’re starting from scratch and you don’t have any issues in your plan yet, now’s a good time to start adding them in. Either start high level by creating epics and breaking them down into tasks, or simply list all your work to be done as independent tasks. If you want to plan at a higher level then epics, watch “customizing hierarchy” in the Portfolio for JIRA demo video to see how to set up additional levels of hierarchy.

3. Calculate your team’s throughput

The most significant value that Portfolio for JIRA provides is calculating a realistic, data-driven roadmap for your team’s work. While the scheduling algorithm takes into account many variables, all plans can be simplified to their basic form of cost, scope and time – a formula that any project manager will be well versed in. As kanban doesn’t involve sprints, you cannot use the same definition of velocity and on top of that, estimates are also used less with kanban teams as each task is intended to be of a similar size. So how can work out a suitable measurement for planning a long term roadmap? Read on.

Let’s start with getting a realistic velocity that represents how much work your team gets done on a regular basis. What we want to do is calculate your teams throughput – the number of work items that is typically completed in a given period of time. Kanban teams that use story points can determine that using story points per week, otherwise you can describe this as issues completed per week. If you’ve already started working with JIRA Software then this can be extracted from your reports. In reports, go to your “Control Chart” and “Cumulative Flow Diagram” to identify the “Work in progress” and “Cycle time.” To calculate throughput we’ll follow Little’s law: Throughput = Work in process/Avg. cycle time

Little’s law: Throughput = Work in process/Cycle time: Take the average cycle time for a data range that is the most reliable reputation of your team’s performance. Calculate it as a decimal relative to a week. So with an average cycle time of 4d 12h I calculate 4.5/5 = 0.9. JIRA Software doesn’t really have a way of directly calculating the average Work in Progress so this is something that will have to be approximated using the Cumulative Flow Diagram. Refine the report by your “In progress” columns (including any other columns you’d count as progress such as Testing). From this example the average WIP is approximately 8 issues. So now we can calculate the Throughput (8/0.9) to be 9. This will be used as your team’s weekly velocity. Make sure you regularly measure and validate this number to ensure you have a reliable roadmap.

control-chart cumulative-flow-diagram

4. Estimating the scope

Following kanban practice you should have approximately same-sized tasks. Define 1 story point = 1 issue so your team’s velocity is equivalent to their throughput of tasks. You’ll need to add a story point of 1 to each issue in your Plan’s scope table. If you have any work items that happen to be larger or smaller than normal, then that can be represented by increasing/decreasing the estimate. For example if a story is half the usual effort than the estimate can be 0.5, or if it’s double the standard effort then you can set the estimate as 2. Now when you hit calculate you’ll have a projection of work items in a schedule. When it comes to estimating epics that haven’t been broken down into stories – it is up to your judgement to approximate the breakdown.

Use default estimates:We’ve brought back default estimates in Portfolio for JIRAv2.0.6 so if you have a large number of issues you can simply set the default story estimate to 1.

5. Playing with milestones or releases

Now that you have informed Portfolio for JIRA of your resources and scope all you need to complete is the time section, dubbed “releases” in Portfolio for JIRA. In the Releases tab you can define releases or milestones for each project. Kanban releases tend to be unplanned as they’re simply delivered when features are completed. If this is the concept you’d like to follow, then you can simply let Portfolio for JIRA tell you when you’ll hit each release by setting “dynamic release dates” in the release details.

Or, you may want to time-box particular release dates. In this case, use the “fixed end date” on your release to specify when a certain set of work items need to be released. Portfolio for JIRA will let you know if you will hit or miss that particular release date. If you’re set to miss a release date (assuming they are hard deadlines) then you’ll need to either de-scope work items or add more resources to your team. Portfolio for JIRA’s easy-to-use commit/reverting of changes allows you to easily examine the “what-if” scenarios to investigate your options.


6. Committing back to JIRA Software

So far we’ve generated quite a general schedule based on simplified data of your team to get a basic idea of your delivery dates. If you’re happy with this level of granularity then you can commit the changes back to JIRA Software so that any data changes are exposed to your team. At this point you’re free to create new issues, change the priority of issues, add specific team members to teams and assign them to issues within your portfolio plan. You can go much deeper with your plan by adding work stages for your issues, skills for your team members in order to visualize bottlenecks, dependencies to work on tasks sequentially and a whole lot more.

Whenever you make a change, simply hit calculate to update your projected roadmap and then commit your changes to JIRA Software. Thanks to Portfolio’s commit/revert (link to info) you can project “what-if” scenarios for your kanban plan. This plan setup also gives you the flexibility to roadmap your kanban and scrum together in the same plan. As long as your scrum teams use story points you can use the standard concept of velocity and story points and Portfolio for JIRA will accommodate both practices.

Already using kanban with Portfolio for JIRA? We’d love to hear more! Let us know in the comments below so we can reach out. Happy planning! ?

Start using kanban with Portfolio for JIRA

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now