Pull scheduling allows developers to grab work from a backlog. 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.”
Software features vary in value (to the business). To align the flow (of features) to maximum business value, empower a product owner with decisiveness to prioritize the backlog. Healthy software has business value, so factor in gradual repayment of technical debt. 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.”
For co-located teams, the physicality of a Kanban board is great, acting as an information radiator. 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, JIRA 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.
Posts
