A key concept around user stories is that they should ideally embody 7 properties, which are usually represented by the acronym INVEST. What's NOT often talked about is that creating stories that follow all 7 of the guidelines in the INVEST acronym simultaneously is actually pretty hard. The various "generally good" properties can often be in tension, and getting stories to follow one can often mean trading off another.
I don't think enough time is spent thinking about why following all the tenets of INVEST is difficult. I don't think teams always recognize clearly that they ARE making tradeoffs, and that they could make different ones. And I don't think all teams communicate well about those tradeoffs are, why they've made the choices they have, and understand what might cause them to reconsider.
This week, I want to talk about the most important tensions I see in INVEST. I want to raise awareness that some of these tradeoffs are hard, and present some ways of thinking about how to make the right tradeoffs for your project.
What's INVEST anyways?
For those of you who aren't familiar or need a refresher, INVEST represents 7 properties that "ideal" user stories should have. They are:
- INDEPENDENT. Good stories should not have implicit dependencies on other stories. This is important because it gives us one of the key advantages of Agile - that our product owner should be free to choose the order in which to play the stories based on business value. When stories have dependencies, there's an implicit sequencing - you can't play story D until after A, B, and C.
- NEGOTIABLE. Stories should describe the business problem rather than a specific implementation. This allows negotiation/back-and-forth between the skilled development team and the product owner on what the solution might look like. Non-negotiable stories lead to "because I said so" development, where the team does what they're told without having input. It's also a leading cause of "it's what I asked for but not what I need."
- VALUABLE. Every story should have a clear tie to why it delivers business value. If a story doesn't deliver meaningful business value, why should we spend time on it? This is often expressed in the "so that..." or "in order to..." clause of the one-sentence story formulation. Stories that don't express value clearly are likely to be deprioritized by the product owner (or, if we actually do them, frustrate the product owner by doing something they don't care about). Related - "valuable" stories are our method for having "thin threads through the system" - end-to-end slices of useful end-user functionality. If we don't focus on keeping stories valuable, we can wind up splitting "build the database for X" from "build the UI for X" into different stories, neither of which is actually useful to an end-user.
- ESTIMABLE. Stories should be sufficiently specific that the development team can estimate the relative complexity of implementing that story. Stories that can't be estimated are difficult to fit into iterations, because they take away our ability to determine what's "reasonable" in a given timeframe.
- SMALL. Stories should be as small as reasonably possible. A single story that takes 4 weeks to implement is not only difficult to fit into a single iteration, but it also reduces our ability to track our own progress. It's much easier to track done/not done than it is to track "I'm 45% complete with this story." Keeping stories small makes planning easier, prioritization easier, execution easier.
- TESTABLE. It should be obvious to everyone on the team (including the product owner) when a story is complete, and the team can move on to another story. This means we need agreed to, testable conditions of completeness. This is often expressed in terms of acceptance criteria (e.g. an "I will know I am done when...." list, a set of "Given/When/Then" criteria, or any other agreed-on formulation).
Small vs. Valuable
The single most common tension I see on teams is trading off Small vs. Valuable.
"Valuable" stories have a clear tie to something that delivers clear business value. i.e. we know why the story makes the user's life easier. "Valuable" is often the Product Owner's domain on the team - the Product Owner is often the person articulating the business value, and needs to understand it to help the team prioritize effectively.
"Small" stories are in a working size that's effective for the team. As an upper bound, stories should be no larger than can fit in a single iteration. Most effective Agile teams use stories significantly smaller than that, which helps maintain a healthy workflow (having several smaller stories finish over the course of the iteration is easier to track than one story that's "worked on" all iteration and finishes at the end.)
The tension arises because, with a little creative thinking, any story can almost always be split into smaller pieces (i.e. there's no "smallest POSSIBLE size"). Teams can generally choose the granularity they want. However, the smaller we split the story, the harder it is to maintain a clear grasp on how each individual piece delivers business value. If we split far enough, we'll pass the point where our Product Owner can understand why a given piece of work is important to deliver value, and we won't be able to prioritize effectively.
For example, let's say we have a story like "As a customer, I want to view my shopping cart online prior to checkout, so that I know what I'm buying." But that story is estimated at six weeks. Maybe we break it up into "view order basics," "view items," "view item quantities," "view total price for each item," "view order subtotal," "view order taxes," and "view estimated shipping charges." OK, still reasonably clear how all those items are valuable. Then "view estimated shipping charges" has to break down into "view shipping charges for ground items only," "view shipping charges for air-eligible items," "view shipping charges when there are hazardous items," "view shipping charges for international items..."
At some point, we pass the threshold where the set of stories we break down into are so far removed from the thing the product owner actually wants ("I want to see my shopping cart contents before checkout") that it becomes difficult-to-impossible for us to clearly see the value proposition for each one. Asking the product owner to prioritze the 12 stories related to seeing the shopping card against the 15 stories for checkout and the 29 stories for selecting items is a very difficult task. On the other hand, asking the development team to work on a project that has only 3 huge stories (because they're the things the product owner cares about) is likely to have serious planning and workflow issues.
How do we reduce this kind of tension? First, if nothing else, be aware that the finer we carve stories into pieces, the harder each is to prioritize (and vice versa). Second, most teams I've seen be successful target a certain story size. If you're one of those teams, talk about how that's working in your retrospectives. Don't be afraid to suggest your stories are too large to execute (or so small that we can't get a clear prioritization). Third, ensure that WHEN you split stories, the team is focused on ensuring that each sub-story is valuable (e.g. do NOT split "build the UI" from "build the business logic.) Fourth, consider how you parallelize stories - is a story that's "too big" something that could have two developers (or two pairs if you're pairing) work on different pieces at the same time? And if so, does that make more sense than splitting into two smaller stories we need to torture to express as "valuable"?
I think a bigger issue here is whether User Stories are in fact really the right unit for BOTH prioritization and workflow, but that's my article for next week, so stay tuned.
Small vs. Negotiable
A central principal for most Agile teams is to defer decision making until the "last responsible moment" - the moment when we have to make the decision in order to avoid future pain. Having negotiable stories is the embodiment of this principal - we deliberately elect to defer deciding on implementation details until we've come to the point where we can't reasonably proceed without those details.
As noted above, we can in principal split stories ad infinitum if we wish, and often will do so to ensure stories are small enough to fit our "standard" granularity. And (as we just discussed) one thing we want to ensure we do when splitting stories is to keep each of the substories valuable. It's very easy, however, for this to mean that we lose negotiability - as we split a story into smaller pieces, we start making decisions on how we're going to implement the story, and each piece becomes a story.
For example, we might have a story like "As a returning customer, I want to be recognized during a future puchase, so that I won't have to re-enter all my information." If that story is too large, we might break into stories like "As a returning customer, I want to provide a username and password when I check out, so that my previously used information can be retrieved," and "as a returning customer who logged in successfully, I want to select a previously used shipping address during checkout, so I don't have to re-enter the data," and "as a new customer, I want to be prompted to optionally register an account and provide a password during checkout, so that I can be recognized in the future.
All these sub-stories are potentially small, and all seem valuable. But notice that we have a lot more decisions made about how the feature will be implemented than we had in the original story. We're using a username and password (as opposed to, say, storing the information in a cookie on the user's machine for later retrieval). We added a step the checkout process to choose a password (as opposed to, say, sending an e-mail with the option to register post-purchase). We have the ability to select from multiple previously used shipping addresses (as opposed to the most recent one).
All these decisions might be correct, and this might be the best implementation. But by breaking down the story this way, we've clearly implied a number of details of the implementation, and so reduced the negotiability of the story. Creative ideas the developers might have (for example, using a third-party ID tool instead of rolling our own) may be squeezed out.
How can we reduce some of this tension? Again, a big piece is awareness - understand that when we have a story that needs to be broken down, we might need to make certain decisions. Second, make sure the development team is involved in those decisions - if we're not going to restrict their available choices by our choice of stories, let's make sure that the way we're breaking this down is what the development team thinks is correct (as opposed to being "the only way the analyst who broke the story down could think might work.")
Independent vs. Small
Sorry, Small. I know I'm picking on you, but you're hard to do well.
As mentioned above with "Small vs. Negotiable," one common artifact of the process of breaking a story into smaller, valuable pieces is to make certain technical decisions up front, thus reducing the overall negotiability of a feature. A related common practice is break a given story up into smaller pieces by creating smaller stories that need to be done in a required order to be meaningful, which means they're not longer independently prioritizable.
For example, if we're building what we've decided is a three-step registration wizard, we might break it up into the logical steps the user goes through, like "Provide personal contact details in the wizard," "Provide address details in the wizard," "Provide payment details in the wizard," "Check the data collected by the wizard for errors," and "Create the profile based on wizard data." As noted above, this breakdown is less negotiable, but lets say we talked it over with our developers, and we all agree this is the right way to do registration.
Now we might have a different problem, which is that the stories are assuming they need to be done in order. If the only way to get to the "Payment Details" is from a button on the "Provide personal contact details," then logically we need to do contact details first. And we probably can't do "check for errors" or "submit" until we've collected all the data.
The problem with creating "flows" of stories like this is two fold. First, we've reduced our ability to reconsider pieces of the flow - if we decide later "You know what? Storing payment data is a security risk we don't want to take, and it's not really hard to re-enter it, so let's cut that story," then we have to re-work (at least) the "check for errors" and "submit" stories, and maybe others. Second, by having flows, we can "trap" ourselves for development - if the stories MUST be done in an order, then we can't do story 2 until story 1 is done, and can't do story 3 until after story 2. This means we "single thread" on these stories, which means we can't have more than one in play at a time (since they depend on each other). This can lead to long lead times.
The first thing I'd consider to reduce this tension is thinking about whether we've actually split the stories the right way, or if there's a different split that allows more independence. The piece that's suspicious to me here is the separate "check for errors" and "submit." A possibly better split would be "collect personal information from a wizard and save it to a profile," "collect address information from a wizard and save it to a profile," and "collect payment information from a wizard and save it to a profile." Rather than needing to build up a whole profile before saving, add the mechanism with each piece to error check and save that piece. If we want to do the "payment" story first, so be it. We might have (at least temporarily) profiles that are just anonymous payment information - is that actually a problem, or just a different way of thinking about profiles? That's not to say EVERY dependency issue can be resolved by a different splitting of stories, but it's sometimes the case that we block ourselves by thinking too narrowly about our options (in my example, thinking of the "profile" as an atomic thing that we need to build completely before submitting).
Negotiable vs. Estimable
When stories are negotiable, a range of potential solutions are possible, so long as we solve the underlying business problem. However, a "range of possible solutions" can be difficult-to-impossible to estimate.
For example, a story to "provide feedback to a user when they are missing required data elements on the registration form" could be as simple as re-displaying the form with the missing fields highlighted in red, or could be as complicated as providing a wizard to guide the user through the form, with step-by-step instructions translated into the user's language.
It would be nearly impossible for a reasonable development team to provide a single estimate that covers both ends of this spectrum that has any degree of accuracy. On the other hand, if we decide that, in order to be estimable, we will choose to estimate the first option (redisplay with a color highlight), then we've reduced negotiability and made a choice that we might regret later (when we have a great framework we need in 6 other places to provide text guidance, but we have to do something different here because "the story says to."
To resolve some of this tension, a good practice is to separate the necessary (the business problem and the acceptance criteria) from the assumed (the specific implementation we're assuming in order to estimate). I like to keep a separate "estimating assumptions" section in stories, where we clearly record what assumptions our estimate was based on. Related, we need to revisit these estimating assumptions - if it becomes clear that the way we're going to implement the story is different from what we assumed earlier, we should revisit whether the estimate still makes sense. Finally, we need to set the expectation with the team that solving the business problem is more important that justifying our estimate - if there's a better way to solve the problem than the one we assumed when we estimated, we will pursue the better solution rather than justify our estimate.
Negotiable vs. Testable
I actually see two separate sources of tension here I want to tease apart.
First, similar to the tension with Negotiable vs. Small, there's a temptation to assume a specific implementation in our acceptance criteria for a story, either to make the story more concrete, or because there's only one possible solution in the mind of the person writing the acceptance criteria, and they don't realize other solutions are possible.
Second, similar to the tension with Negotiable vs. Estimable, a story that's highly open to a variety of options is very difficult to plan specific test cases for. We can't plan what we're going to test if we don't know exactly what the code is going to do yet.
For the first tension, I think it's important to think about our acceptance criteria as different entities from the tests we're going to execute to ensure the code works properly. Acceptance criteria ought to be "properties that EVERY acceptable solution to the problem must have." It takes thought to make our acceptance tests implementation agnostic. It also introduces a translation step - when we test the actual implementation, we need a mapping from the abstract "thing we need" to the specific "what we're going to do."
Consider the following two formulations:
- GIVEN I have not provided all the required registration information, WHEN I attempt to register, THEN I should get clear feedback that my information is incomplete AND I should be told what additional information is required.
- GIVEN that I have not filled our some required fields on my registration form, WHEN I submit the form, THEN I should see my form re-displayed with an error message at the top and the missing fields highlighted in red.
The second tension is more a question of when we need to do the translation from an abstract "need this to be true" into "we will do the following to know that it's true." It's virtually impossible to practically test a user story if you don't know whether you're submitting a form full of data or retrieving information from a third-party repository. At some point, we need tests specific to our chosen implementation.
There are a few things I suggest to lessen this tension. First, just as I suggested separating the "necessary" from the "assumed" when talking about Negotiable vs. Estimable, I suggest separating Acceptance Criteria (describing the necessary) from Acceptance Tests (describing how we'll verify we meet the acceptance criteria). Ideally, we present the developers with the Acceptance Criteria, and work out the details of the Acceptance Tests with them when we're ready to implement the story and so have to pick a specific design. Related - just as it's often an anti-pattern to have too large a backlog of fully fleshed out user stories, we should resist the temptation to build significant test plans for stories we haven't yet begun to work on. One technique I've found successful with multiple teams is to have a "story kick-off" with the analyst, testers, and developers (and ideally product owner) when we start development on a story. This ensures we have a common understanding of what the goals of the story are, and that the developers can articulate their expected vision for the implementation of that story. This allows the testers to develop more concrete test cases to the actual design "just in time" when the actual design is known.
As I mentioned earlier, I could go on with this - there are a lot of other places where there can be perceived tension between the various tenets of INVEST (Independent vs. Testable, you got lucky this time...)
What I hope I've accomplished in an overly-long blog post is at least illustrate WHY there are potential tensions, and that no matter what you're doing on your team, you ARE making some of these tradeoffs. If things are going well, you're probably making the tradeoffs that work well for your team, so well done. If things are frustrating, hopefully I've suggested some places to look and some balances you might want to revisit.