Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far, the universe is winning.
RICK COOK EM THE WIZARDRY COMPILED
Don’t be offended with the provocation if you’re programmer or if you are a user. We are now mature enough to understand that there is not easy translation between the languages of business and development environment. And this is the reason that impelled me to write this post. Give me more 2 minutes. Don’t give up now.
Starting from the beginning – What is INVEST?
INVEST is another one of those cool acronyms that help to fix a relevant content. Created by Bill Wake, it servers as a gentle reminder of what a quality product backlog needs to compromise, in addition, it refames the SMART acronym for the context of product development (software, but flexible enough to the development of any product).
Invest means:
Independent
Negotiable
Valuable
Estimable
Small
Testable
It is also worth mentioning that this methodology is strongly recommended by Mike Cohn in his publications (see the book here at this link).
A painful truth
We do not or should not expect software to be viewed by users and software engineers the same way. I’ll go ahead, We shouldn’t expect that whatever the product is, it will be seen and evaluated in the same way by those who use it and by those who manufacture it.
Draw an analogy and reflect, in a “magic” show, would a professional illusionist have the same experience as the rest of the – lay – audience? Would the perceived values be the same?
Now apply this to the relationship between doctor and patient, accountant and citizen, programmer and final user and etc. Is the premise still true? Well then, let’s move on.
Converting an expectation into a viable product is a complex task and it is not just about producing the desired item, we need to understand that it is about converting one domain into another.
I explain, it is a communication starting from the origin that speaks the language of one universe to the destination that speaks the language of another universe. Each one on a different shore, separated by an entire ocean of experiences, preferences, stories and so on.
It is then up to us, who transform an idea into a product, to translate and fragment the desires and needs into communicable and feasible parts, reducing the chances of failure and losses throughout the process.
This is where the INVEST makes perfect sense.
Independent
It is much better to complete 80% of the stories than 80% of each story
Robert C. Martin in: Clean agile – Back to the origins
Independent tasks are easy to plan their execution and also to execute in parallel, and can be a great ally of the project team, reducing possible delays or even increasing the backlog of deliveries.
There will rarely exists, if ever, be projects with uniquely independent tasks. Even so, try to write the stories as independently as possible. Even though a tasks needs to wait for the right moment to be executed, it need understand the beginning, middle and end in itself, so everything you need to understand the beginning of a tasks and decree that it has been completed, is within itself.
Negotiable
The details of a tasks needs to be co-created with whoever will perform the task. The sponsor certainly knows very well what he needs, but he doesn’t know how to do it as well as those who will do it, therefore, work for several heads to carry out.
Define the tasks, negotiate its acceptance criteria, negotiate how and when and if needed, negotiate again. A project is a living organism.
Imagine that throughout the execution of the project, by monitoring and learning from its development, the sponsor identifies a way to add even more value. Shouldn’t this be accepted by immediately? Well then, negotiate.
Now think about the scenario where something defined in the project ideation phase is really not possible to be added for a justifiable reason. Negotiate a viable exit.
Never let the development team estimate more than a sprint and a half. The chance of estimates “losing their validity” in these cases is very high due to changes in architecture, dependencies, priorities, etc. and as a result we waste the time it took to estimate.
Luis Duarte in Scrum and agile methods: A Practical Guide
Valuable
A story needs to be valuable. We don’t care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive
BILL WAKE EM INVEST IN GOOD STORIES: THE SERIES
them as important.
With this analogy, Bill Wake means that we should “cut vertically” the cakes layer and not horizontally, otherwise we’d serve only the topping. then only the dough, then only the filling and so on. That doesn’t look like a birthday cake, right?
This requirement is a big challenge when you need to divide requirements into stories (epics into stories, if you prefer). Bill Wake recommends thinking of a story as a multi-layered cake (a birthday cake, for example), when we are dividing a story it is as we’re serving a piece of the cake.
When thinking about a software product, it is best to think about stories in a way that can be used by the user. Creating all the tables in a databases but not being possible to access them can be a lot of work, but it doesn’t deliver much value to the customer, just like having a system interface designed but which cannot be used by the customer because it doesn’t connect with others parts of the system. These are examples “horizontal cuts” that should be avoided when we want to write good user stories.
Estimable
Saying that a story needs to be estimable doesn’t mean that its value has to be precise or that this value must be written in stone, because if it were, the concept of negotiable would not make sense, right?
A good story needs to be estimated enough to help with ranking and scheduling its implementation. Otherwise, see, ten story of five point should not be together in the same sprint if the team’s production capacity is thirty points, it makes sense? In this case, having estimates on the stories will help team prioritize and select the stories that should be together in the next sprint.
Small
Good stories tend to be short, and so their descriptions. Not that we should save information, just not include things that make reading and understanding the story confusing or controversial. Alistair Cockburn describes story cards as “tokens promising a future conversation”.
Shorter stories tend to have greater estimation accuracy, reduce implementation risks and are easily verifiable.
Testable
If a customer doesn’t know how to test something, it may indicate that the story is not clear enough or that this story doesn’t reflect something of value. Or it can also indicate that this customer needs help formulating his request and consequently the test cases.
Clients tend to describe only the happy path of an activity, forgetting all the exceptions that need to be considered in the routine of an activity. Preparing a product for these exceptions can easily be the biggest effort in the development and consequently of product as a whole.
Finally
Writing good stories is a multidisciplinary activity and should be done in groups. From idea to the execution through planning and estimates requires revisions, negotiations, adaptations, comparisons, etc. None of this can be done without the involvement of those who design those who execute.
Try adopting the acronym INVEST the next time you think about developing a product. If you remember, come back here and comment on your experience. To the next.
Access content about INVEST and much more on Bill Wake’s XP123 website by clicking here and downloading the e-book about INVEST at this link.