At Pivotal, our teams use an agile project management tool called Pivotal Tracker. This software enables real-time collaboration around a single, shared, prioritized backlog. A product manager uses Tracker to write fine-grained user stories using a syntax that supports our opinionated development process. Most feature stories contain a scenario and acceptance criteria, using the Gherkin syntax to define and communicate user value. Here’s what that template looks like:
As a persona
I want to do a thing/be prevented from doing a thing
So that user value
Given preconditions
When actions
Then results
This works well for conversations within the product team, and between the team and the product owner, who are all focused full time on the product and its progress. For a startup, this could describe all the necessary—and all the interested—parties.
Product teams that are part of larger organizations often find their stakeholders must spread their attention across multiple product teams. For casual users of Tracker, the level of detail intrinsic in small feature stories in Gherkin can be disorienting. With all these details in the way, it can be difficult to keep the big picture in view.
Fortunately, Tracker includes the concept of epics, larger scale stories or themes that can be used to group smaller feature stories into more abstract descriptions of user and business value. By directing casual users to a list of epics, we have found that they can stay informed about the product team’s progress without getting mired in the details of the Features backlog. And they are more likely to remain engaged in the agile XP process.
The epic story type includes a description field, just like the one in the feature story type. How can this be asset leveraged to communicate higher level business value for the product stakeholders?
From experience with feature stories, we know a standard syntax reduces cognitive overhead, so we’ll look for a variation of the feature Gherkin. Since the stakeholders tend to be business focused, a formal business hypothesis format is a strong contender. The goal is to craft a premise with defined goals that can be proven or disproven (measured) as the epic is built and deployed.
The first part is the value statement:
For customers
Who do a thing
The solution
Is a something (the “how”)
That provides this value
Next come the business outcomes, which state the benefits to the business if the hypothesis is proven correct. This is followed by leading indicators, the early metrics that will tell us if we’re on the right track. Finally, the nonfunctional requirements outline the systems that will have to be built or altered to support the epic.
Unlike competitor, current solution, or nonexistent solution
Our solution does something better (the “why”)
Here’s an example using a pseudo-real-world business hypothesis:
For third-party contractors
Who make changes to our data
The Snowball Epic
Is a streamlined workflow
That provides 24/7 access to a secured portion of our database
Unlike the current ZIP file export/import model
Our solution is more stable, has a shorter cycle time, and increases transparency
Business Outcome Hypothesis
Leading Indicators
Nonfunctional Requirements
With this level of description contained in the product epics, stakeholders can easily access most of the information they need on a day-to-day basis.
When the product manager tags the stories associated with an epic, Tracker can display progress toward completion. A stakeholder will never be at a loss to provide a status update. And they have a low-barrier introduction to the power of Tracker!
Judy van Soldt is a Staff Product Manager at Pivotal Labs.
Category: Productivity
