Scrum and Kanban for the Enterprise

Watch a video on how to use the kanban board in codeBeamer here.

What is agile?

Introduction

Starting in the late 1990s, software and generic engineering process has seen an explosion of lighter-weight and ever-more-adaptive models. These models assume that - with the right tools and practices - it was simply more cost effective to develop the product quickly, have it evaluated by customers in actual use, be "wrong" (if necessary), and quickly rework it than it it was to try to anticipate and document all the requirements up front.

The movement to these agile methods has been the most significant change to affect the software enterprise since the advent of the waterfall model in the 1970s.

These methods have proven themselves to deliver outstanding benefits on the "big four" measures:

• Productivity
• Quality
• Morale
• Time to market

Notable agile methods include Extreme Programming (XP), Scrum and Kanban, all of which are discussed in details over the web.

The 3 levels of agile

In large organizations, agile is implemented in three levels.

Team level

At the Team level, agile teams of 5-9 team members define, build, and test user stories in a series of sprints and releases. In the smallest enterprise, there may be only a few such teams.

The responsibility for managing the things the team needs to do belongs to the team's product owner.

Program level

At the Program level, the development of larger-scale systems functionality is accomplished via multiple teams in a synchronized Agile Release Train (ART). The ART is a standard cadence of timeboxes iterations and milestones that are date- and quality-fixed, but scope is variable (no iron triangle). The ART produces releases or potentially shippable increments (PSIs) at frequent, typically fixed, 60- to 120-days time boundaries.

Product managers are responsible for defining the features of the system at this level.

Portfolio level

At the Porfolio level, investments themes are used to assure that the work being performed is the work necessary for the enterprise to deliver on its chosen business strategy. Investment themes drive the portfolio vision, which will be expressed in as a series of larger, epic-scale initiatives, which will be allocated to various release trains over time.

Agile process frameworks

Scrum process

Scrum is an iterative and incremental framework, which focuses on "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal". Scrum is the most widely known and practiced agile process framework.

Learn more about Scrum in Wikipedia.

Kanban process

Kanban puts an emphasis on just-in-time delivery while not overloading the software developers. In this approach, the process, from definition of a task to its delivery to the customer, is displayed for participants to see and developers pull work from a queue.

Kanban promotes the following core practices:

1. Visualise: Visualising the flow of the inherently invisible knowledge work and making it visible is core to understanding how work proceeds. A common way to visualise the workflow is to use a card wall with cards and columns. The columns on the card wall representing the different states or steps in the workflow.
2. Limit WIP: Work-in-process (WIP) at each state in the workflow is limited. New work is “pulled” into a state only when there is available capacity within the local WIP limit.
3. Manage flow: Flow of work through each state in the workflow should be monitored, measured and reported in order to be able to evaluate positive or negative effects on the system.
4. Make policies explicit: With an explicit understanding of how things work and how work is actually done, it is possible to move to a rational, empirical, objective discussion of issues.
5. Implement feedback loops: Collaboration to review flow of work and demand versus capability measures, metrics and indicators is vital.
6. Improve collaboratively, evolve experimentally: Kanban encourages small continuous, incremental and evolutionary changes that stick, using scientific approaches.

Learn more about Kanban in Wikipedia.

Agile for the team

Team is the lowest level of implementing agile. Many agile practitioners only focus on this level, although Intland believes that the agile value delivery stream should span from teams to the whole organization.

User stories

The basic unit of work for the team is user story. The team's objective is to define, build, and test some number of user stories in the scope of an iteration and thereby achieve some even larger value pile in the course of a release. Each story has a short, incredibly intense development life cycle, ideally followed by long-term residence in a software baseline that delivers user value for years to come.

Learn more about user stories in Wikipedia.

Managing user stories

User stories are represented by issues in User Story type trackers in CodeBeamer. There is one tracker of this type created in each new project, called intuitively "User Stories". You manage user stories the same way like any other type of issues, but we quickly go into details in the next sections.

Creating user stories

You can create a new User Story as any other type of issue. You can either add it on the tracker page or on the tracker list using the context menu.

A User Story is just a regular tracker item with one special field: story points. Story point is a relative measure of the complexity of a User Story. You can specify one or more baseline user stories (preferably with different complexity), define their story points value and then use these to estimate the complexity of other stories in stoy points.

In Codebeamer the Story points field accepts any integer without restrictions.

Breaking user stories into actionable tasks

Often times, a user story is too large to be implemented as a single unit of work, and should be broken into multiple actionable tasks. For example, to implement a new report type, you need to:

1. add new indexes to the DB schema,
2. extend the data access code with a new query,
3. and implement the web view to display the report results.

The default "User Stories" tracker is kept on the bare minimum, thus expressing this relation is not available out of the box. Nevertheless, you have multiple option to express "implemented by" between user stories and tasks, change request, bugs, and other types of issues:

1. Easy: simply associate the user story with each additional issue it is implemented by.
2. Better: customize the "User Story" tracker. Add a new multi-value reference type field "Implemented by". In this case, the relation is stored at the user story end.
3. Best: customizeeach of the trackers that potentially can contain actionable tasks for user stories. Add a new reference type field "Implements" and make it required. In this case, the relation is stored at the task end.

Sprints

The basic unit of agile development is the sprint (or iteration, in more general) - the ability to take a set of user stories from the backlog and refine, code, test, and accept those stories into a new integrated baseline within a fixed timebox. The goal of each sprint is the same: to build an increment of potentially shippable code that is of value to the users.

A sprint is typically between one to four week long, during which the team completes the work defined in the sprint backlog (see the next section).

Learn more about sprints in Wikipedia.

Releases

(Important note: although releases are parts of the Team level according to our structure, they are discussed here, in context with sprints.)

The development of system functionality is accomplished via multiple teams in a synchronized Agile Release Train (ART), a standard cadence of timeboxed iterations that are date- and quality-fixed but scope-variable. The ART produces releases (or potentially shippable increments (PSIs)) at frequent, typically fixed, 60- to 120-day time boundaries.

The release is to the enterprise what iterations are to the team: the basic iterative and incremental cadence and delivery mechanism for the program. It's important to note: releases can be delivered to the customer, or not, based on the business context (not discussed here).

Managing releases and sprints

Releases are represented by top-level configuration items in Release type CMDB categories in CodeBeamer. Sprints are simply child items of releases. Essentially, this hiearchy represents the "one release is split into multiple sprints" relationship.

You can create, update and delete releases and sprints as written in Release Management with codebeamer.

Managing and ranking backlogs

The term backlog was first introduced by Scrum, where it was described as a product backlog. In this enterprise model, product can be a pretty nebulous thing, because various teams may be working at various levels, so there are multiple types backlogs in the big picture. Therefore, the use of te term backlog is more generalized here.

The backlog is the one and only definitive source of work for the team. It holds all the work that needs to be done, like a "todo list". It contains user stories, but also other issue types like a bug that needs to be fixed, a task or a change request that needs to be done, or a manual test that needs to be executed. The backlog is managed by the team.

There are three kinds of backlogs exist, each with a different scope:

1. Sprint backlog: the work to be done in a specific sprint.
2. Release backlog: the work to be done in a specific release (which typically consist of multiple sprints).
3. Product backlog: the work to be done on the product at some point, maintained and managed collaboratively by the team.

Backlogs are ordered by relative order in which the user stories should be done. The order is typically specified by many factors, like business value, the penalty for not doing that story, risk, cost and so. (These are not discussed here.)

Setting the relative order within a backlog is called "ranking" or "prioritizing" the backlog.

Learn more about the (somewhat limited-scope) product backlog in Wikipedia.

Managing the product backlog

The product backlog is the list of issues that have no target release set. There is no special page in Codebeamer to manage this list, but you can add the issues to releases on the browse tracker pages. You can use Mass edit to change the release field of multiple issues at the same time.

Managing the release backlog

Release backlog is the prioritized list of issues in a specific release. You can access it by clicking on a release link in a release category.

By default, the issues in the backlog are ordered by priority descending (with the exception that closed and resolved issues are always at the end of the list) but you can change this order on the release planner.

Managing the sprint backlog

The sprint backlog is the prioritized list of issues in a sprint. You can manage this list exactly like for any other release (described in the previus section).

To create a sprint just click on the New Sprint item in the menu of a release. In Codebeamer all releases that are not on the top level are sprints. To move issues to the sprint backlog you can use the issue editor page or mass edit (to move multiple issues at once).

Agile for the program

In the previous section, we introduced the Team level, the place where the software teams define, develop, and test the software for the solution. At the next higher Program level, we suggest an organization, process, and requirements model that provides mechanisms to harness some number of agile teams to a larger enterprise purpose - the delivery of an entire product to the customers.

Features

The primary goal of the Product Vision is to communicate the strategic intent of the product. Vision is best expressed by Features in the agile world. Features describe what the product will do for its users, and the benefits the user will derive from them.

Managing features

Features would be most efficiently represented by issues in a custom "feature tracker" in CodeBeamer. Although this tracker type is not available out of the box, you can implement it easily by creating a requirement type tracker and customizing that.

We suggest adding the following fields to a "feature tracker". Some of them may be omitted in your configuration:

• "Realizes": a reference field to the Epic (an issue in the "epic tracker") which a particular feature realizes
• "Value": estimate of how much benefit users can derive from a feature
• "Effort": rough estimate of how much work implementing a feature takes (in story points)
• "ROI": computed field with the formula value/effort, the first approximation of Return on Investment
• "Cost of Delay" (CoD): the penalty for not delivering the feature on time

Learn more about customizing trackers.

After the feature tracker is in place, you manage features the same way like any other type of issues.

Agile Release Train (ART)

Please see the ART detailed in the "Releases" and in the "Managing releases and sprints" sections above.

Agile for the portfolio

For smaller enterprises, up to 100 agile practitioners and one or two products, the Team and Program models may be everything they need to operate in an agile manner. Bigger enterprises, employing hundreds or thousands people and offering many products, needs another level of abstraction, on the Portfolio level.

Investment themes

Investment themes (product themes) are the initiatives that drive the enterprise's investment in systems, products, applications and services. They represent key value propositions that provide marketplace differentiation and competitive advantage.

Investment theme examples: Customer Relationship Management, Social Intranet, Computing Resources.

Managing investment themes

Investment themes are best represented by issues in a custom "investment theme tracker" in CodeBeamer. This is essentially a requirement type tracker, that is further customized.

We suggest hiding most of the fields of a default requirement tracker, and write investment theme summaries that are clear to every stakeholder. A high-level classification can be done by introducing a "Type" choice list with the following options:

• "Into existing": create value by enhancements and maintenance
• "Into new": create near-time value by creating new products
• "Into future": create products that don't add immediate value, but will do that in the future

Epics

Investment themes drive all new development. Epics are derived from these decisions. Epics are large-scale development initiatives that realize the value of investment themes.

To understand the full relationship between the agile entities:

• Invesment themes are realized by epics.
• Epics are realized by features. Epics are managed in the Portfolio level.
• Features are realized by user stories. Features are managed in the Program level.
• User stories are realized by tasks. User stories are managed in the Team level.

The elegance of this hierarchy at implementation time is that if you set up the "realizes" field in each of these trackers, you get 100% traceability. You can nicely trace back any tiny source code change from its tasks, through its user story, its feature, its epic all along to its investment theme.

Managing epics

Epics should be represented by issues in a custom "epic tracker". This should be a requirement type tracker, with further customizations applied to it.

Consider adding the following fields to it:

• "Realizes": a reference field that points to the investment theme realized by a particular epic
• "Business value"
• "Efforts"
• "Alignment to investment theme": the degree of alignment chosen from a choice field with options 0, 0.25, 0.5, 0.75, 1.0.
• "Weight": ranking weight. It should be a field automatically calculated from the formula (business_value/efforts)*alignment

Executing agile

What is a cardboard?

If you have a manufacturing background or if you are developing agile, you probably have come across the term "Kanban". Kanban is a methodology to visualize workflow in the value-added process. The workflow stages are represented by columns on a board. Typically this board is put on some wall in the office or in the factory. The most basic board consists of 3 columns, "ToDo", "In Progress", "Done".

codeBeamer's cardboard is based on the Kanban board, but slightly modified and enhanced with some features. It can be used to show you quickly how well you workload is distributed across the workflow. It also provides "one-click" modifications to the workflow or attributes of single items on the board.

The cardboard can be reached by clicking on the cardboard icon, which can be found next to a Release or Sprint in "Releases" or in the Planning Board view:

Viewing issues in cardboards

On a cardboard you can see all issues assigned to a release in the same order as defined in the release backlog (which is either the order by priority or the order set by manually sorting the issues). Depending on your configuration you can get warnings if there are too many or too few cards in a column.

The size of the cards changes adaptively on resizing. They always take up as much space as possible while trying to fit as many cards in the same row as possible.

Analysis of a card

A card on the board looks like this:

The vertical stripe on the left side of the card is used for moving the card. You can grab this "handle" and drop the card to an other column. Its color is determined by the status of the issue.

There are several important pieces of information on this card:

• key and id of the issue: Clicking on this link will open the issue on a new tab/new page (depending on the browser)
• photo or monogram of the first assignee
• the priority icon
• the summary of the issue. If the user does not have permission to see that field, then [Summary not readable] text is displayed instead.
• the icon in the upper-left corner indicates the type of the issue and its color tells you its status. If the user does not have permission to see that field, then the color is always grey.
• the pencil icon below the priority (visible only when the cursor is above the card) is for editing the issue. Clicking on this icon will open an overlay where you can change the details of the tracker item.
• under the priority there's the story point value set for the issue
• next to the story point value there is a colored tablet pointing to the user story of the item (if available)
• in the bottom-left corner you can find the link(s) to the release(s) of the issue
• finally, the bottom-right corner shows the list of the assignee(s) and the releases that this card is assigned to

Hover over the user story to reveal the full text:

You can also hover over the release and assignee links to show them all:

Mapping issues to cardboards

Cardboards always have four columns that you cannot remove: ToDo, In Progress, To Verify and Done (you can change these labels, see in the section about configuration). To which column a card is put depends on the status of the issue. Codebeamer uses status flags to map statuses to the columns. The logic is the following:

• if the status has the Closed flag set than it is mapped to the Done column
• if the status has the Resolved flag set than it is mapped to the To Verify column
• if the status has the In Progress flag set than it is mapped to the In Progress column
• otherwise (if the status doesn't have any flags set or it is the Unset status) it is mapped to the ToDo column

You can change these flags on the choice list configuration page of the tracker. Select Customize in the more menu of the tracker then click on the Choice Lists tab and select Status. Note that a cardboard can contain issues from several different trackers. So if you want to change the mappings for all similar statuses then you have to change the choice list configuration in each of the trackers.

Filters

Cards can be filtered using the repost widget.:

Using this filter you can select multiple options and build complex criterions. You can use the same filter options as on the reports page but the release id is always added to the query.

You can save and reuse predefined reports using the "hamburger icon":

Grouping cards

You can group the card based on several properties using the group by icon:

After selecting an option the issues are put in horizontal groups:

The group header show the number of cards in this group, the sum of their story points and the group label.

Note that even when the cards are grouped you can only move them horizontally, that is you cannot move them between groups (updating the grouping property this way is not possible).

The order of the cards

You can change the order of the cards (within their columns) using the order by icon:

Editing in cardboards

Updating issues directly in cardboards

Clicking on the edit icon in the top-right corner of a card will show the standard issue editor in an overlay. This way you can edit the issue without leaving the cardboard and losing context.

To change the status of an issue you can also move the card between columns.

Create New Downstream Reference

From codeBeamer 9.4.0 you can create New Downstrem Reference for the items by using the context menu of the card, and selecting a tracker under Create Downstream Reference menu option.

Moving cards between columns

Cardboards are very useful in updating the statuses of the cards. To update an issue just grab a card. The colums where you can drop will immediately change their color to green and show the name of the status.

With workflows

If the tracker of the card you're dragging is using workflows than the columns for the transitions available for that card will be marked with a green placeholder:

The placeholders show the name of the transition. Dropping the card to one of the green areas will update its status.

If the target status has any required fields then after dropping you will be shown an issue editor overlay where you can set those fields.

Without workflows

If the workflow is not active on the tracker of the dragged card than you can drop to those colums to which there are statuses mapped from that tracker.

The green placeholders will tell you the name of the status. As you can see a column can contain multiple placeholders.

The gray area shows the original status of the card.

Access control in cardboards

There are a few reasons why you cannot move a card on a cardboard:

• you don't have the permissions to edit the issue at all. To fix this you must change the tracker settings.
• there are no workflow transitions for the current status of the card.

Readonly cards are marked with a little "pin" icon and their tooltips tell you the exact reason why you cannot move them:

There is an other circumstance when it is not trivial what should be done after a card was dropped. When the tracker of the card has some required fields then you must set those whn updating the status. For this purpose after dropping such cards you'll get an issue editor overlay window where you can make sure that all required fields are set properly. Note that you always get this overlay window, it doesn't matter if the required fields are empty or not.

Propagating status in cardboards

Cardboard view can handle distribution and aggregation rules set on the status field of the trackers. These rules mean that updating the status of an issue has some effect of its parent or children. For example if the Close recursively rule is set then when an issue is closed all of their children also get closed recursively.

Cardboard makes this kind of status propagation very visual. After dropping an issue to the Done column (to a closed status) all its children will follow it and they will move to the same column.

Configuring cardboards

You can configure the Work in Progress values and the column labels for each cardboard. The configuration page can be reached by clicking on the Kanban Board Configuration item in the menu (but it is only available if you're a Project Admin). Note that the changes you make on this page will only affect the current cardboard.

The first tab of the cardboard configuration page (Column Configuration) shows the same columns as the cardboard itself. Each column is very similar except the Done for which you cannot configure the MIn/Max values.

For each column you can set the Work in Progress limits: a minimum and a maximum value. If a column on the cardboard has less cards than the minimum, or more than the maximum then you'll get warnings like this:

If you leave an field on the configuration page empty that means that there's no limit for that column.

You can also configure the column labels: the cardboard will use the column names that you specify here.

A third configuration option is labeled as Display cards from child sprints. This is checked by default. This means that not only the items linked to the release will be shown on the cardboard but also all issues that are linked to one of the child releases. You can simply disable this by unchecking the box.

Beside configuring these values you can get some useful information on the configuration page. In each column there's a list of tracker statuses mapped to that column. You can change these mappings on the configuration pages of the trackers.

Information shown on the cards can be configured through Kanban Board Configuration menu:

It is possible to enable / disable different sections of the cards:

Changing number of columns

In Cardboard Configuration new columns can be added. Columns added by the user can be also removed. The four built-in columns cannot be removed. Cardboard must have at least the four default columns.

There is a default maximum limit on the number of columns, which is 10. If this limit is reached then an information box appears on the top of the configuration screen to notify the user. To change this maximum limit (e.g. to 15), edit general.xml and use this XML configuration:

<interactive cardboardMaximumColumns="15" ></interactive>