I’ve touched on User Stories on several occasions, my favorite being Why Your User Stories Suck! Today I’m here to share with you a very common, yet very commonly overlooked, way to check each and every User Story on your backlog to see whether or not it’s really “ready” for your Dev teams. One of the most frequent causes of delays and slowdowns in most Agile implementations that I’ve seen comes from a lack of balance in the User Stories that the team is being given to deliver — stories that are too big, or which are dictates, or which just exist on the backlog because “someone asked for it”. What we need to do as Product Managers is to occasionally take a close look at each of our backlog items and make sure that they meet the INVEST criteria — Independent, Negotiable, Valuable, Estimable, Small, and Testable. If we do this simple gut-check on a regular basis, we’re far more likely to see our teams succeed and to reduce the amount of time wasted in long, drawn-out planning sessions.
Independent
This is probably the most common stumbling block that I see teams run into, especially in the early phases of an Agile transition — they have a story, but there’s a dependency on something else being done by another team that they want to run in tandem, with the hope that it will all come together by the end of the sprint. It won’t. Trust me, you might get lucky some of the time, but don’t let it fool you…the minute you count on a dependency being resolved, it will fall and you’ll fail the sprint. The value in having an independent story is two-fold: (1) the team knows that they’re in charge of their own destiny, and can’t blame another team for their failure; and (2) it forces us to think about dependencies before we start, and to get them into the plan. Nothing lights a fire under another team’s ass like the words “We’re blocked until you deliver this.” It also makes us think of creative ways to break dependencies, such as documenting and mocking an interface so you can finish the UI while the backend is still under construction. Especially in teams where a hybrid waterfall/Agile process is being used, independence is the key to your ongoing success.
Negotiable
…up to a point. Specifically, user stories are intended to be the start of a conversation — and that conversation can happen and should happen up until the point at which the team takes in the story. The specifics of the story, the Acceptance Criteria, any mocks or other requirements that you create are all able to be updated, changed, or even rewritten completely up to the point that the team takes it in. Once that happens, the only “negotiation” is one-way, starting from the team and going outward. If something is unclear or needs to be tweaked in the dev’s opinion, only then can the requirements change. The sprint is a sacred space of commitment — nobody should be allowed to change anything in the sprint other than the team members themselves. Teams need to understand this, as well as the business — the only plan that matters is the sprint plan; up until it’s taken in, there’s no commitment or guarantee on anyone’s part as to what the work will be or when it will be done.
Valuable
When your team looks at you during sprint planning and asks, “So, what’s the reason for this?” you should be able to provide a clear and concise, user-centered answer. “The CEO wants it” isn’t good enough; “We promised this to a customer” isn’t good enough; “I thought it would be really cool” isn’t good enough. The only acceptable reason for a user story to exist on a product backlog is that it brings value to the customer or the end user. Now, I know what you’re thinking — what about “technical stories”? Simple — even “technical stories” bring value to the customer in some way — “We need to do this database rearchitecture project so that our customers can continue to received intraday reports, otherwise our ETL system will fail or take 2-3 days to process” is a customer value statement. If you can’t figure out some way that your customers will obtain value from the user story, it shouldn’t be on your backlog.
Estimable
The business needs estimates, of some sort and to some degree of confidence, from their development teams. There are just too many other moving parts in a business that need to have some degree of understanding of how big an effort is to ignore the requirement, contrary to what some developers out there might like to believe. Thus, we need to make sure that our user stories have sufficient detail and context so that a developer or team of developers can provide some guess as to how big or small, hard or easy, significant or insignificant the work actually is. Sure, they might be wrong, and they probably are if they’re being asked to give time-based estimates. But “bigger than a breadbox, smaller than an elephant” style estimate are what is preferred in most Agile organizations. To get there, though, we as Product Managers need to understand the needs and dynamics of the team, and the level of specificity they need in order to make those guesses — and to do our best to make sure that everything on our backlog has that level of detail.
Small
User Stories should be small enough to be fully delivered within a single iteration — preferably small enough that multiple User Stories can be completed in that iteration. Making sure that our stories meet this criteria actually has a surprising number of benefits — (1) smaller work items take less time and usually require fewer changes to implement, reducing the risk that any single code change will cause major issues; (2) smaller work items are easier to test, validate, and demo, reducing the cost of testing especially when integrating work into a larger whole; (3) a backlog consisting of small items is one that allows the teams flexibility in their work, especially if one story “blows up” unexpectedly and they need to put it back on the backlog and take in something new. Small amounts of work also reinforce the feeling and practice of incremental success and incremental development. When you complete a small thing, then another, and another, it’s surprising how quickly you’ve actually achieved something monumental.
Testable
So very many development teams forget that this “little” thing is a key to the whole process; your user stories need to be clear enough and defined enough that not only do your developers know what they need to build, but your testers know what they need to test. Any known issues need to be called out; any “corner cases” that you can anticipate need to be documented; any “gotchas” that the team is likely to hit or that you want to be sure are covered need to be there. A user story cannot be considered “complete” until it’s been designed, implemented, and tested. While I prefer test-driven development and SDETs tasked with automation, however you do it, make sure that your testing teams are part of the sprints and especially the sprint planning. They will think of things you haven’t — that’s their job, and we should embrace it.
