Unity Ads delivers targeted video advertisement to hundreds of millions of mobile phones at staggering rates. We have six teams building the platform at our Helsinki office. All the teams are able to deliver all parts of the product to production several times a day every day.
We have wholeheartedly embraced the uncertainty in product development. We work in a fast paced industry where new companies and technologies come and go and each can drastically alter the whole landscape. We realize we need to innovate and implement accordingly. We admit that we can only make educated guesses on what will work and what will not. So we experiment, measure results and learn. Everything in our process aims to make experimentation fast, economic and safe.
To make this work, one of the most important things we focus on is making the batch size of work as small as possible on all levels. For teams this means small and high quality user stories. These will be the focus of this blog post.
Continuous Deployment means that all changes made to the software are deployed to production as soon as they are ready. We deploy software to production several times a day.
My definition of good user story in continuous deployment environment is:
“The smallest increment we can make, from working software to working software, that still brings value or proves a hypothesis.”
Breaking down my definition, it contains two challenges: bringing value and being a small increment. Developers often struggle with focusing or defining the value in each story. Product people struggle with the fact that most of their feature requests are bad ideas. To get to a working idea, the fastest way is to make small hypothesis, get it to production and prove it, and then iterate.
When discussing the goals behind features, it’s important to switch from calling them requirements to calling them hypothesis. When we are in an uncertain or fast changing environment, you can’t really have requirements. This naming change encourages experimentation. We should be allowed (even encouraged) to say that “we are unsure if this feature will bring the benefits we expect, so let’s find a way to verify the assumptions with minimal effort”.
The teams here works towards goals not features. Getting there usually starts with the teams asking for the goals behind feature requests. You can use a technique like the annoying but sometimes effective “Five Whys or just more probing discussions. In the end, you should clearly understand the reasons why a specific feature is beneficial.
When the goal is clear, the next thing we hunt for is “the smallest increment that still brings value or proves a hypothesis”. It’s easy to split stories on a technical level so they make sense to implement but so that alone they don’t bring any value. I strongly discourage this.
It is very easy to have the whole team busy completing technical bits and pieces for weeks only to realize that first time the whole thing is usable for the customer will still take few weeks or months of integration work. The most common culprit I see is the split of story to “frontend part and “backend part”. Neither brings any value alone and often when implemented apart it requires many iterations and neither implementer gets the satisfaction of “delivering anything.
Generally the aim is to figure out “how can I throw away 80% of the story and still deploy working software that we can learn from”? You should elaborate the original story and make all the steps and constraints it has explicit. If it turns out the feature describes a workflow or a “wizard style, consider if it’s possible to deliver only one or few of the workflow steps. Are there variations in the feature? Consider implementing just one of the variations first. Richard Lawrence describes similar patterns in his blog with more detailed examples.
A great way to encourage the developers to shift their focus from delivering code to delivering value was to make team decision to have a product demo every two weeks. In each demo only show working software from staging environment. No excuses, no showing stories or burndown charts. This has the effect of having developers consider “what will I have to show for this in the next demo when planning each story.
There is relatively little good resources on the topic of good user stories and methods to arriving to those. This is surprising, considering the importance of the topic for the success of your whole organization and ability to do meaningful continuous deployment. Agile Alliance lists the following resources:
Twenty Ways to Split Stories, 2005
How You'll Probably Learn to Split Features, 2008
Patterns for Splitting User Stories, 2009
InfoQ: How to Split User Stories, 2011
Splitting User Stories: the Hamburger Method, 2012
Let me know if you have others you have found useful!
Big thanks to Heikki Tunkelo and Samuel Husso for all the feedback while writing this article. This was originally published on my LinkedIn page.