Janne Sinivirta
Software architect, agilist, programming language nerd, game dev by night, fitness enthusiast and proud father of two. Development Director at Unity Technologies.
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.
Definition of Good User Story
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.
Value Hypothesis
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.
Safe Increments
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.
More Resources
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.
Great timing. Was looking for some insight like this. Thanks.
This is something I've been wondering about. I've seen teams increasingly working on "visual" stuff so that checkpoints are all about delivering features. Not so bad on its own, but it's made me wonder: how do you manage tech-debt in that kind of environment?
You are right that this thinking could be abused. I'll make two points on this:
We trust our developers and encourage them to include technical-debt reduction and refactoring in to the stories. So if doing thing A properly requires that I start by improving the existing code base then you do it, we won't question you.
"What will I have to show" is just one way of teasing out the essence of what you are doing, it should not be the defining metric for prioritising your work.
But like with all in agile, we need to focus on honest communication between product needs and responsible development. Maybe I've been lucky but with the teams I've used it with it has worked well and people were not afraid to still pick "invisible" tasks when they considered them important.
Great article. On the point about frontend/backend separation I think it depends on whether the backend is an open API and a product in of itself. I.e. the API is value itself. What we have found is that shipping frontend and backend together often results in APIs that are too narrowly focused on a single frontend use case. Also when considering a distributed system where frontend and backend are often many separate physical systems deployed separately, you end up with dependency chains that make deployment more complex (not impossible though). We deploy many times a day and we try to limit a story to a single physical unit of release, this is a technical constraint but it makes deployments much easier to rationalise about and easier to manage dependencies.
We manage a distributed system with hundreds of separate services that interact with each other and creating stories that have no sympathy for this means our pipeline slows down significantly while teams rationalise about what has to ship together.
We have automated most of this but ultimately the dependencies need to ship before the dependants, even if this is seconds.
It does mean that we often write stories that are too technical in nature or separated on boundaries which make it difficult to see the value.
I'm wondering if anyone has any insights into these sorts of scenarios.
Our current thinking is that if you are doing microservices and aren't relying heavily on messaging, you are doing something wrong. In part exactly for the reasons you outlined above. Microservice should be deployable in isolation. So if it depends on bunch other services being available when it is deployed, it isn't "deployable in isolation". Crafting services with well-picked business boundaries and letting messaging be the transport layer, you get services that don't care if their "dependencies" are up when they are.
Yes, but what we are talking about here is frontend / backend separation, not inter microservice communications which I would agree are better served via async persistent messaging. Our frontends communicate with backends (microservices) via RESTful APIs and I was referring the trouble of creating a story that covers both vs separating the story to cover them separately.