Sunday, 1 January 2012

About Business Value And Issue Trackers

Pull scheduling allows developers to grab work from a . This way of team working is efficient — flowing around impediments — and effective — developers understand software — but is not necessarily well aligned with the business.

Maintaining A Backlog

I hear many people complain that it is hard to define business value. So they won't do it. Or they won't try any harder to do it.

Joseph H. Little, Defining Business Value

Software features vary in value (to the business). To align the flow (of features) to maximum business value, empower a with decisiveness to prioritize the backlog. Healthy software has business value, so factor in gradual repayment of . Over time feature valuations drift, either in response to an evolving business environment or as domain knowledge is won. So, review valuations regularly.

Tracking The Backlog

An information radiator displays information in a place where passersby can see it. With information radiators, the passersby do not need to ask questions; the information simply hits them as they pass.

Alistair Cockburn, Agile Software Development

For co-located teams, the physicality of a board is great, acting as an . Where distribution favours a software solution, use a big screen to radiate backlog and activity feeds to those co-located.

A good issue tracker is a flexible tool, and convenient for backlog tracking. When used so, invest in careful configuring: though similar in structure, an Agile backlog is not a list of defects, differing in several subtle — but significant — semantics.

As the team learns to create higher quality software, the number of defects should fall over time. As the team delivers business value, demand — and the backlog — should increase. Successful teams should expect these queues to move in opposite directions over time: defects shrinking but the backlog growing.

Issue Priority Is Not Business Value

Most issues trackers include a priority quality. For example, priority is selected from BLOCKER, major, minor, trivial and so on. These traditional names carry with them baggage from conventional bug and release management.

This issue priority may differ radically from business value. Behaviour considered unacceptable when wearing a test- and release-hat might reasonably be given a high issue priority, but only the view under a business hat shows the business value delivered by work on this issue.

Avoid conflating these concepts: add a new business value field. Whimsical names (for example gold >> silver >> iron >> paper >> blue skies) are memorable, and help avoid misunderstandings and misuse.

An Example

5 minutes might sound like a long time to wait for a screen to load. From the testing perspective, this might be a seen as a major issue.

However, this does not necessary mean that improved start-up time would bring major business benefit. A business might expect an employee to open the screen in the morning, and then go to make their coffee. The screen would remain open all day, closing again only at night. For this business, value lies in responsiveness and stability but not start-up time. Lengthy start-up would then be a major issue with paper business value.

In this case, reasonable valuations reached wearing tester and business hats would result in seemingly opposing assessments — until understanding that each measures a different quality. Fitting both qualities into a single field encourages wasteful conflict where there should be harmony.

Search This Blog