In the early days of Agile, Bill Wake published guidelines for writing good user stories. He created an INVEST acronym and promoted SMART for creating goals. This is what I discuss in this segment.
Let’s start from start by defining user stories. A user story is a narrative device used to articulate feature function desires by users. A user story is not a requirement. We’ll discuss that in a moment.
User stories are constructed in a format capturing the user, the desire, and the value proposition. A typical construct employs this syntax:
As a certain type of user, I want some functionality because of some objective value proposition.
Let’s disintegrate this sentence.
Certain type of user is a placeholder for what might be called a role, an actor, a persona, or something along these lines. It’s a particular classification of a person using the system. As not all people have the same needs, and might approach it differently, we need to account for each of them so we can design appropriate solutions for them.
A user might be a high-value customer, an infrequent customer, a new employee, an experienced employee, a freshmen student, a floor nurse, a charge nurse, or someone else. If different types of people interact with the system differently, each needs its own story.
The I want clause represents the desired function. This is not a feature, per se. It should be system agnostic. After all, perhaps the solution lies outside of the software system. Maybe it belongs in a different place in the system. An example might be that I want a widget on my dashboard that shows me the current stock level.
Does the user really want to know the current stock level? Maybe the user replenishes stock when the inventory runs to 10 per cent of capacity. So the solution is not necessarily to see the current stock level. What she needs is for the replenishment order to be automatically submitted when an eligible product reaches its replenishment level. If it’s a fast-moving item, perhaps, the system could understand the velocity of depletion and prescribe a solution based on these data. Perhaps the system could learn about depletion and fulfilment trends and determine what the optimal carrying level for each inventory item should be, alerting the user to exceptions. How one frames a problem, expands or limits the solution set.
Finally, there is a value proposition. If this functionality is implemented, what is the expected benefit? This value might be in the form of new revenue, protected revenue, cost take out, process velocity or throughput, time-savings, learning, or anything along these lines. It should not be vague and should be measurable—even if the measurement strategy and implementation is not yet available. Ideally, this would also come with a hypothesis.
As a product manager, I want to determine whether the average user wants to know pricing, so that I can reduce call centre contacts.
There are many ways to determine this, but one way might be to install a button that says click for pricing and capture how many unique visitors click the button versus those who don’t. This method is very quick and easy to implement. I could save you a step and tell you categorically that your customers want to know the price without contacting you, but if you need to test that theory, be my guest. I won’t deign to shame the companies that fail to provide prices for internal reasons unrelated to customer experience. You know who you are.
Now that we’ve established what a good user story is, let’s continue.
According to Bill Wake’s classic INVEST checklist a good user story should have these elements. I N V E S T.
The I in invest is independent.
A story should be mutually exclusive of others. It can relate to a single feature function, but each aspect needs to be unique.
The N in invest is negotiable.
As already mentioned, user stories are not requirements. They are functionality ideas open to negotiation. Consider the earlier example. The best idea is not necessarily the first idea. And the solution may be accomplished in a different scope. The team should have some latitude to negotiate the solution.
The V in invest is valuable.
Part of the syntax of a user story is the value proposition. Any functionality is probably competing among requests for other functionality. And this isn’t even accounting for other products, projects, and programs competing for a limited budget. Upon implementation, the value should be measured to determine if the time and effort were well spent.
The E in invest is estimable.
Can we at least tee-shirt size a guess at cost and effort? We might not know if we can develop it in 37 hours and 12 seconds, but we should know if this is a week, a month, or a year. If it’s a week, that’s fine. If it’s a month, it might be overspecified and need to be broken into smaller stories. If it’s a year, it is definitely too large.
The S in invest is small.
This is a perfect segue. Smaller user stories are more likely to be estimable. Less is more, but don’t micromanage and create non-negotiable requirements—at least not in Agile, and not for a user story.
The T in invest is testable.
Can you test that the function works and provides the proposed value? If we provide relevant prices on our commerce site:
- Average order size will increase by 10%
- The average number of items purchased will increase by 25%
- Cart abandonment will diminish by 20%
- Price-related call centre inquiries will drop by 80%
Are these outcomes guaranteed? No. They are educated guesses. Do we already have baseline figures against which to judge these? If not, we’d better start collecting or analysing historical data. Are there other initiatives that might also account for a change in any of these? Measuring attribution is critical, but that’s a topic for another segment.
Follow this INVEST approach, and you should end up with better user stories. Before moving on to SMART goals, let’s spend a few moments discussing how Bill Wake arrived at the invest acronym. He wrote about this on his own site.
Essentially, Bill employed a Design Thinking approach known as Affinity Clustering. He jotted down all of the things common to good user stories, and he grouped them into common themes. Per his account, he brain-dumped some terms:
Isolated, independent, separate, distinct, non-overlapping, important, valuable, useful, discrete, explicit, and so on.
Grouping independent, isolated, separate, distinct, and such, he was looking for a catchy acronym. At least a memorable memetic instrument. Et voilà, invest jumped out.
And that’s the end of that chapter.
Let’s change gears to SMART. Bill also promoted this concept for how to write good goals. Upfront, I’d like to point out that if you use SMART, the result is objectives, not goals.
A goal is directional but not measurable. I like to think of it as a positive binary condition.
Goals are desires in the nature of: We want to increase revenue. We want more customers. I want to attend university.
These goals can only be evaluated as true or false—yes or no. There is no measurement component relative to extent.
Objectives are goals with a measurement attribute. We might begin to turn the previously stated goals into objectives by adding measures, as follows:
We want to increase revenue by 10 per cent
We want to double our number of subscribers
I want to attend university with at least a 3.5 GPA
These are still not complete, so let’s return to them after reviewing SMART.
The S in SMART is for specific.
As with the I in INVEST, we want the objective to be independent. We need to have an unambiguous understanding of what is being referenced.
At our company, we want to increase gross revenue. This is specific. We are talking about the company as a whole, and we are talking about gross revenue rather than net revenue.
The M in SMART is for measurable.
We’ve discussed this at length already. We need to have some way to determine that we’ve met our objective.
At our company, we want to increase gross revenue by 10 per cent.
At some point, we can measure to determine whether or not we have satisfied our objective.
The A in SMART is for achievable.
I might want my company to increase revenue by a thousand per cent, but this is not a likely scenario. Although there may be overlap, aspirations are not the same as objectives.
Depending on the company and the marketplace, at our company, we want to increase gross revenue by 10 per cent, may or may not be achievable.
The R in SMART is for relevant.
If you are building an eCommerce site, an objective like, ‘at our company, we want ten per cent of employees to ride bicycles’ may be an admirable vision, but it is irrelevant to the project. Even if having your team all ride bicycles would help the company meet this goal.
The T in SMART is for time-boxed.
We need a specific end date.
At our company, we want to increase gross revenue by 10 per cent is not a good objective. Are we targeting a day, a month, a year, 5 years, or what?
A SMART objective might be:
At our company, we want to increase gross revenue by 10 per cent year on year from last calendar year.
This has all of the SMART components. It’s specific, measurable, achievable, relevant, and time-boxed. We can extend a similar treatment to the other goals we’ve mentioned.
At our company, we want to double our subscribers by the end of the fiscal calendar year.
I want to attend university X and graduate with at least a 3.5 GPA within 5 years time.
These might be amended to be more specific, and that’s fine. Once we have objectives, we can formulate strategies or approaches to attain these objectives. Indeed, that would make another interesting segment.