In January Gojko Adzic announced that he wanted to write a book about improving user stories. The book has been written and published in iterations, the final version was released in October 2014.
The book fifty quick ideas to improve your user stories aims to help people to write better user stories.
It support teams in iteratively delivering products that satisfy the needs of their customers and stakeholders.
You can read and download a sample of the book from Leanpub. InfoQ readers can buy the eBook at a 50% reduced price using this voucher link. This offer will last until 15 December 2014.
InfoQ interviewed Gojko about the format of his new book, when and when not to use user stories, the ideas that the book provides, organizing product backlogs and prioritizing user stories.
InfoQ: Why did you write a book on improving user stories?
Gojko: Most of the teams I work with as a consultant now have reasonably good technical practices – they can ship software out in a sensible amount of time, with good quality, as long as they get asked to deliver sensible stuff. So the bottleneck has moved away from technical delivery to actually defining what goes into the pipeline. And this is where the majority of teams I meet either end up in water-scrum-fall, or in a stream of consciousness where software is built on a whim without any bigger picture. Stories are almost never challenged or validated from a business perspective – checked if they were good ideas in the first place. Organisations with such teams don't really get the big promise of agile, and I wanted to help them figure out how to plan better and actually benefit from being able to deliver in iterations.
InfoQ: For who is your new book intended?
Gojko: For teams and business stakeholders with some experience in delivering iteratively, but that feel they should be getting more from running an agile process. This book skips over the basics of stories, because David (co-author of the book) and I wanted to offer something more than just the typical advice on the three Cs of stories or making them INVESTable. Instead, we assume that readers already know that, and the book contains experiments and ideas teams can try out to engage stakeholders better and structure iterative plans more effectively. This includes good techniques for splitting big chunks of work into small but valuable pieces, providing a high level picture for effective prioritisation, organising effective conversations to cover all perspectives quickly and so on. For stakeholders, the key ideas are around how to provide better information to their delivery groups, how to set better priorities and how to outrun the competition by achieving more with less software.
InfoQ: Different ways exist for defining, communicating and managing requirements. When and why would you recommend user stories?
Gojko: User stories aren't requirements – they are a way to organise a collaboration on requirements. They fit nicely into short iterative delivery cycles, when there just isn't enough time to write and hand-over documents and when timely alignment is absolutely crucial.
Under a lot of time pressure, and with short iterations that is a constant factor, being able to align, plan and prioritise quickly is a major issue. Because stories rely on collaboration, they help to engage a cross-functional group in understanding a problem and coming up with the right solution quickly.
Stories also put things into the perspective of users, helping to align delivery not by how easy or difficult it is to build stuff technically, but by how important it is to a business stakeholder. This helps to avoid long feedback cycles caused by technical dependencies and local optimisation of development that actually slows down the entire delivery pipeline from a business perspective. It helps to avoid over-engineering of things that should be simple, and allows teams to engage business stakeholders in a more productive discussion.
InfoQ: Are there situations where an alternative approaches than user stories could provide better results? Which ones would you recommend?
Gojko: For organisations without competition, where the market doesn't change during delivery, where the underlying problem is pretty well defined, where developers and testers are domain experts and no surprises will happen ever, stories are probably not that beneficial. I'm not sure what I'd recommend there because I've never worked with any organisations like that.
Stories also aren't a good fit for situations where nobody really knows what's possible or what they want out of the final product. Customer research, prototyping and technical spikes are better solutions for those situations.
InfoQ: The user stories improvements are described in your book using ideas. Why did you pick that format?
Gojko: After the basic level of practice (which we decided to skip in the book), software delivery tends to become highly contextual. Some things work in one context, but might be completely wrong for another. Instead of assuming we know everything about everyone (which we obviously don't), we wanted to create a menu of options for readers to choose from, depending on their context. Some ideas will work better for enterprise initiatives, some will only apply to smaller teams, some will work well with business-to-business delivery, and some will only work with consumer software. We wanted to inspire people to improve in many different contexts, and hope that almost anyone working with iterative delivery will find at least a few ideas to try out.
InfoQ: In the book you provide different kinds of ideas. Can you describe which kinds? What made you choose them?
Gojko: We grouped ideas into five sections. The first part – creating stories - deals with capturing information about stories before they get accepted into the delivery pipeline. The second section, planning with stories, contains ideas that will help manage the big-picture view, set milestones and organise long-term work. The third part – discussing stories - how to discover hidden assumptions and how to facilitate effective conversations to ensure shared understanding. The fourth part – splitting stories - offers several strategies for dividing large and difficult stories into smaller chunks that will help teams learn fast and deliver value quickly. The last part – managing iterative delivery - contains ideas that will help people work with user stories in the short and mid term, manage capacity, prioritise and reduce scope to achieve the most with the least software.
We chose these mostly by value. The book started out iteratively, from an assumption that it would be nice to gather fifty or so ideas and make a book. During the work, we took some things out and started writing a new book (Fifty Quick Ideas to Improve Your Tests), threw away some ideas that didn't seem to fit and prioritised some other things that expanded on areas that seemed valuable to early draft readers.
InfoQ: One of the ideas is to approach stories as survivable experiments. Can you explain it?
Gojko: Teams often struggle selling stories as small chunks of work that need to fit into a sprint. Business stakeholders simply don't care about that (fully justified), because this is purely technical. We end up coming back to organising things that are easy to develop, not that are valuable to a stakeholder.
Small stories are good not because they fit into a sprint, but because an organisation can quickly get feedback from them. A story is supposed to deliver something valuable to a stakeholder, and if so, we should be able to decide if the work is really done or not from a business perspective, learn from that delivery and get ideas for future work. Fitting into a sprint is a consequence of that – because sprints or iterations are cycles of feedback.
So instead of trying to explain stories as small chunks of work that fit into a sprint, it's far better to explain them as small experiments for feedback. Then it becomes interesting to investigate what would we want feedback on – and what would actually be valuable to a stakeholder. For example, how do we know if users will actually like some grand new idea? Well, run a small experiment to deliver part of a value, and measure the results.
Some product ideas will turn out to be great, some will turn out to be wrong – for a variety of reasons including a ton of things outside of our control – for example, depending on what the competition is doing. Approaching stories as small experiments allows business stakeholders to learn through delivery and make better plans, instead of planning for everything upfront.
InfoQ: You stated that "Planning with user stories, if done well, puts business stakeholders well and truly in the driving seat for decisions on software delivery". Can you elaborate?
Gojko: By changing the engagement model, moving to a cross-functional collaboration on defining the product and approaching stories as options for survivable experiments, delivery teams can help business stakholders make better product decisions. They can use delivery to effectively discover the right thing to build, and turn unexpected and unplanned circumstances into a competitive advantage.
But this requires stories to be done well, not just breaking things down technically and calling it stories. Such things don't provide any useful context for feedback, and don't help people make better decisions.
Lots of organisations talk about focusing on delivering value, but it's mostly lip service. For example, the majority of people doing Scrum tend to only measure activity and busyness – the number of points delivered in an iteration, burn-up and burn-downs and velocity. This all measures how busy people were, or effectively how many hours there are in a day. Work is often structured in a way that small increments don't bring anything genuinely valuable to stakeholders, and this is where business stakeholders disconnect from the whole idea of iterative work and push for all decisions to be made upfront – which Forrester research documented in their paper on water-scrum-fall.
InfoQ: There are different ways to organize product backlogs with user stories, some of them are described in the InfoQ news product backlogs with process maps or story maps. What is your view on this?
Gojko: One of the key lessons for me over the last ten years is that stories are great for describing individual small experiments or delivery options, but to really get the value out of that, we need to have something else to provide a big picture view. The big picture allows stories to be put into the context, compared, prioritised and evaluated against other stories. The thing that most people try to use, but we now know fails miserably, is a linear backlog with a huge list of stories – that Jim Shore called Story Card Hell.
Creating hierarchical backlogs that allow teams to both see a big picture but also manage low level delivery items is one of the biggest challenges of iterative delivery today. Over the last five-six years several good models emerged for that, including story maps and impact maps. I think they all have their place and different usages, but the critical aspect of the good ones is that they visualise the big picture – why this thing is being built in the first place – and allow organisations to focus on delivering outcomes and impacts instead of just features.
InfoQ actually published a nice review of a meeting several leading practitioners had about this last year.
InfoQ: In the book you suggest to use low tech ways to communicate stories. Why?
Gojko: People in our industry are obsessed with tools. We love our gadgets so much that we tend to use them even if they get in the way. A whiteboard or a flipchart still beats any on-screen information capture mechanism, and has the added value of several people being able to write in parallel. Hi-tech stuff typically kills story conversations, because it introduces the bottleneck of one person acting as a scribe or a presenter, where all the other participants read e-mail on their mobile phones.
InfoQ: You can also write user stories for nonfunctional requirements for instance by using the quality performance model described in the book. How would that work?
Gojko: The big problem with things people often call non-functional is that they are actually cross-functional, cross-cutting and difficult to pin down as a single on/off switch. Performance, scalability, usability and things like that improve on a sliding scale. They can be improved or reduced through many related stories. And people can get very opinionated and subjective when talking about something being fast or slow.
The quality performance model is a conversation technique that starts a group thinking about different intervals of value for those dimensions, and de-personalises the whole discussion because it focuses on what the rest of the market does. QUPER compares potential product ideas and solutions to the competition and the market, by setting boundaries around when a particular aspect of a system becomes usable (for example, a e-commerce homepage loading in more than 60 seconds is just useless), when it becomes a differentiating factor (for example, homepage loading faster than two seconds) and when further improvements are an overkill (eg homepage loading faster than half a second). Those three data points (called breakpoints in the QUPER language) depend on the market, the competitors, and not on a particular solution we're building, so stakeholders and delivery teams can have an objective discussion about them. QUPER then compares the delivery options to those intervals so we can decide how much we need to do, and where the system needs to be over different releases. I like it because it helps to start a discussion on what needs to be excellent, what just needs to be good enough, and what those two references actually mean for a particular product/market situation. QUPER helps to align stakeholders on how fast is "fast".
InfoQ: In an InfoQ news item on applying use cases in agile Alistair Cockburn is quoted about a technique called "laminating" to structure user stories using the walking skeleton. Your idea is to "put the skeleton on crutches and ship it out". How can you do that?
Gojko: The Walking Skeleton pattern was designed to derisk deliveries by pushing something simple on the target architecture and then building on that. A steel thread of features that provides a backbone for future work. But the recent surge in popularity of continuous delivery created plenty of good tools for pushing things out quickly and repetitively, enabling us to take the walking skeleton approach even further, and deliver value without validating the target architecture. The “skeleton on crutches” idea is to ship out something that can't really walk, but we can use it to get solid feedback on value faster. In essence, to put the skeleton on crutches, so it can't yet walk on its own, then build it up as people are using it. For example, deliver user interfacing aspects quickly even if they aren't connected to the target architecture and then swap the engine underneath after validating that the product idea is good.
While building MindMup, David de Florinier and I ran the billing system on crutches for several months. We used a third-party forms processor to handle the payment workflow, even if this wasn't anywhere close to the final architecture, but it helped us enable a critical workflow for users months sooner. As the number of users picked up, we swapped the bottom parts for something with higher capacity and that is easier to manage. None of our users ever noticed anything.
InfoQ: Can you give some ideas on how to prioritize user stories?
Gojko: Don't. Prioritise impacts, outcomes, business goals. Story prioritisation follows naturally from there.
About the Book Author
Gojko Adzic is a strategic software delivery consultant who works with ambitious teams to improve the quality of their software products and processes. Gojko’s book Specification by Example was awarded the #2 spot on the top 100 agile books for 2012 and won the Jolt Award for the best book of 2012. In 2011, he was voted by peers as the most influential agile testing professional, and his blog won the UK agile award for the best online publication in 2010. Gojko's latest book is Fifty Quick Ideas to Improve Your User Stories.
