Backlog Management

Agile’s Dirty Secret

Agile purists sometimes seem very proud of eliminating “requirements” from the software development process. The thing is, they haven’t. They’ve just rebranded requirements as the “product backlog.”

A team can’t successfully build anything without a plan, and that’s what the requ — uh, I mean backlog — is. At Streamline we use three tools to manage the backlog through its entire lifecycle:

  • Aha! — a product management tool for capturing and forming ideas and product strategy and refining into features.
  • Microsoft Team Foundation Server/Visual Studio — for the granular management of user stories. Because we’re a Microsoft shop, the MS development environment is the best tool for the team to manage their daily work, from user stories to tasks to code change sets.
  • IBM Rational DOORS — for the functional requirements model and more granular trace matrix. DOORS is a powerful, traditional requirements management tool that might not seem to fit in an agile world, but in fact serves as the backbone of knowledge about our products.

INVEST in Good Requirements

Scrum teams should not accept into their sprint package any backlog item that does not meet INVEST: Individual, Negotiable, Valuable, Estimable, Small, and Testable. Your process must include opportunity for the team to determine whether each candidate item meets INVEST, and the opportunity for the team to estimate the effort before the sprint is packaged. At Streamline we hold a couple backlog grooming sessions and a couple estimation meetings during each sprint to work on the items for the next sprint. While this draws the team away from the current work, it is critical preparation for the next iteration.

Just-in-Time and Trailing Requirements

When you’re building a complex software application that will continue to evolve over several years, it is important to keep track of decisions about functionality that are typically made during each agile iteration. If you don’t, you’ll be struggling to remember the intended sequence of steps in some process, or the business rule governing choices in a context-sensitive menu months later when you need to make changes.

Before agile, you would have turned to the massive requirements specification. But that’s the thing those agilists are so proud of eliminating. Instead, you’ve got all those user stories and conditions of acceptance on hundreds, maybe thousands, of physical or virtual cards to look through. What sprint was the original story packaged in? Did we do any other changes since then? Did the COAs actually cover this specific business rule that’s not making any sense now, or did we come up with the rule during the sprint?

Even if you maintain good metadata on your digital backlog (like, what area of the application the user story is for), and you are able to search for key words, the completed product backlog is still more like the pieces of a jigsaw puzzle — and if you’re under the gun to package an enhancement you’re not in the mood for games.

At Streamline, we believe in just-in-time requirements and maintaining a living functional requirements model. We manage the product backlog in the traditional agile way — high level features decomposed into actionable user stories with conditions of acceptance. Teams groom and decompose and estimate, and stories are packaged. We only specify enough for the team to know what to do. But here’s where we divert from the agile purists: during the sprint, the team also captures the complete requirements in a functionally organized requirements model. The conditions of acceptance are converted into traditional requirements (“The system shall…”), and additional requirements that the team identifies are also documented. Even if functionality is easy to understand by using the software, so granular requirements are not necessary, business rules can be opaque and are especially important to document.

During each sprint, the team also links their test cases to these requirements so that we can collect metrics on functional test coverage. The model supports a trace matrix that allows us to track from a bug through a test case to a functional requirement, over to a related business rule, and up to the original user story.

This functional requirements model serves as an analysis tool for future requirements. We can see all of the related requirements to the one we’re considering changing, as well as the scope of the test cases, and whether there are any existing bugs. The investment the team makes in the requirements model pays off for the product owner and business analyst preparing features and stories for future sprints.

Calibrating Business Value

When you’ve got five software products managed by five product managers, how do you know that they’re all using the same scale when they assign business value?

You don’t. At least, not if you don’t pay some attention to calibrating across the organization.

The other day we had a lively discussion as we looked at completed user stories from our various backlogs and the business values that they’d been assigned. Participants included not only the folks in backlog management roles (directors, managers, and business analysts), but also scrum team members and folks from sales, IT, and client services. It was a fantastic opportunity to show these non-development team members that engineers do want to deliver value!

Nobody in the room knew all about all of the products. But once we’d presented the fundamentals of how business value is used in scrum and a way to evaluate a story, most everyone reached similar values on stories that they understood. We explained our existing scale (zero to three hundred points in ten point increments), and then we suggested some criteria:

  • What percentage of existing clients want it?
  • Is it for the primary user persona?
  • Has it been validated through customer development?
  • Is it sizzle or steak?
    • Is it primarily to help sales close deals?
    • Is it a technical change that will retain existing clients?

Then we presented a series of examples and asked the group to assign value (see the image above). For some, consideration of the number of impacted users was a revelation. For others, abstracting business value by not somehow tying it to revenue was pointless. And for a few, accepting that solving our own problems, like improving deployment or fixing the logo on the home page, has no business value was really tough to swallow. Nonetheless, everyone left with a clear understanding of what those numbers mean on our work items, and the product management team is going to do better at calibrating their value assignments with their colleagues’. That’s a win.

The Client Feedback Loop

If any organization has discovered the secret to producing error free software I’d like to hear about it. For most of us, if your teams were to take the time to make their working code absolutely flawless, by the time they’re done the market window will have closed and the users will have bought a different app. You almost always have to release software that still has some flaws, so you have to include a way to manage prioritizing and fixing them in your lifecycle.

Software development does not happen in a vacuum. Agile practices effectively bring business stakeholders into the development process to better steer teams toward creating software that solves real world problems. But what about the other end of the process? All of the agile process diagrams show the feedback loop where input from users is fed back into the agile backlog. But how does an organization realize that loop?

The tools that manage support cases are not designed to manage development work and vice versa. While plenty of these tools offer integrations to the other kind, it’s not just about being able to create an item over there when your daily working tool is over here. Support staff and other client-facing roles — who may be the best proxies you have to actual hands-on users — need to know what information is critical in an item in the development backlog and also how the development backlog is managed.

When is priority evaluated and assigned? By whom? How can I check up on where my item is in the list? How can I influence the prioritization decision? Have I provided enough information for someone to analyze the problem?

Our product teams conduct change management meetings that include these stakeholders. Everyone sees what’s in line to be done next and can weigh in on which item goes first. But talking about priority is not the same as making the creation and tracking of an effective work item a part of daily workflow rather than a disruptive special task.

At Streamline Health we do not have a full integration between our development management system (Microsoft Team Foundation Server (TFS)) and our support management tool (Salesforce). Client-facing folks have to find the TFS web portal to create a work item when they need help from development to solve a client issue.

The other day we had a lunch and learn session called “TFS for Non Developers.” You can believe that the support and other client facing folks were there, even though this one was a “bring your own lunch” session.

Although we’d presented this material before, regular refreshers, even for those who’ve been here for a while, are a great help in keeping the lifecycle process moving like a well-oiled machine. We showed the audience how to get to the TFS web portal and where to find the backlogs that they care about (structured by product). We reviewed the required fields and why they’re necessary. We showed them how to create and save their own queries, and how to create their own alerts. And probably most importantly, we gave them links to both external resources like the Scaled Agile Framework website, and internal guidance documentation.

An effective agile implementation must include cultural acceptance of principles that the framework depends on, like:

  • Transparency
  • Information Radiation
  • Accountability and Responsibility

Helping our client-facing team members understand that they can look at the backlogs at any time, and that they are responsible for communicating their needs to the development teams in a usable form, is our responsibility. Only then can everyone be held accountable for delivering and maintaining excellent software.