Guest post by Alice Thode Jensen from Copenhagen-based digital agency Reload
In a fixed scope project we can pack research and analysis into a phase upfront and thereby control the spending, but how should we do it in a continuous agile setup?
We Can’t Groom the Backlog by Magic
I’m not going to sell agile or list the reasons we want to be agile in this article. The world is changing at a fast pace around us and we often operate in more complexity than what we can possibly comprehend in one go. I assume you have already bought into that and have had your struggles.
One thing is acknowledging how we live in a continuous cycle of change, learning and adjustments and how it doesn’t work anymore to wrap our strategic initiatives into big heavy planned projects. Another thing is to be able to master a new way forward.
I still often talk to people who use agile methodologies in the “implementation phase” only. So discovery and UX research is already done and scope is actually pretty much fixed when they start to “be agile”. Even if they do try to loop more discovery work and UX research into their agile development processes, how it’s done best is a struggle.
Scrum is the most widespread agile method and it’s a good framework for the development / implementing part, but it doesn’t say much about how we ensure to make the right solutions. Scrum doesn’t ensure we get the right stories in the backlog, we can’t groom the backlog by magic! We need to make sure we actually take advances of the ongoing learning and make sure that we spend the right amount of time chasing the right learnings, otherwise we can just as well embark on big heavy projects.
We have been experimenting a lot with how to balance discovery and delivery and here I will give you a few insights into what is actually working for us.
Continuous Roadmapping
One of the most important tools we work with is our Roadmapping which is heavily inspired by Gojko Adzic’s Impactmapping. The crucial thing is that our roadmapping isn’t a linear plan, we acknowledge how we typically will have more roads leading to Rome and often will have to probe our way forward, as we don’t actually know upfront which way is the best.
Our roadmap always consists of 3 levels:
Our Business goal
Someone is investing in us doing our job and they expect to get something back. Why invest in this initiative, what do we expect to get out of it?Expected change of behavior
We can only make change happen if we get someone to act differently, to change behavior. That means someone should start or stop doing something, or doing more or less of something (or the opposite: someone should NOT change behavior, typical if mitigating risks).
Solution idea(s)
Ideas for a solution we can choose to develop/implement which we believe will enable our expected change of behavior and eventually help fulfilling our goal.
Here’s a sample roadmap as we create them:
With this structure upwards is why? and downwards is how?
This also gives us a tool for prioritisation, we can’t prioritise between ideas without prioritising which changes of behavior, we want to support. And we can’t prioritise which changes of behavior we should work to support, without prioritising what business value we want to invest in.
So, we are actually mapping out the different ways towards a specific goal, we can work towards in an explorative manner. We can try one way out in a small scale, see if it works and continue if it does, or try something else if it doesn’t. We can add new ideas when we come up with them and delete ideas if we realise the assumptions behind them are false.
Budgets are Value Driven in Nature
A project budget often includes several business goals. Solution ideas in a complex structure of assumption chains wrapped in one big business case often make room for some really bad business decisions. If one solution comes really easy, another could be way too expensive compared to the value of it, yet the overall project can still be perceived as a great success.
Budgets must follow business goals, we shouldn’t spend more money on fulfilling a goal than what we expect it to be worth to us - as simple as that!
As everything in our roadmap is mapped up towards a specific goal with an expected value, we can now consider the cost price in relation to the expected value, whenever we decide to invest in work leading to that goal. It could be to explore better solution ideas, research related to an existing idea or actual development and implementation of an idea we believe in.
Of course it’s not always as simple as that and sometimes the value we are looking for is not as tangible as money earned and budgeting for such value can be much harder, but the principle still remains. What we expect to get out of our effort should inform how much we want to invest in it.
Shared Responsibility
By mapping out the three levels, we actually map out the most important assumptions for each solution idea.
E.g: By developing a simple “One page checkout” we assume more visitors with goods in their basket will actually complete their purchase and hereby we assume that we can earn X more money…
By making all these assumptions explicit we enable and encourage everyone involved to take responsibility for doing the right thing. Everyone can point out unrealistic assumptions or bring new or better ideas to the table.
No one just proceeds with solution ideas they think are foolish. Instead everyone takes part in the ongoing discussion of how to prioritise and when to do what.
Question it..
If the basis of a new idea or a way forward is questionable, we define those questions together, come up with a way to find an answer and consider how much such an answer is worth to us.
Questions can then go in the backlog as estimated items along with tasks/user stories with already validated ideas to be developed. Questions on different levels in our map could be:
How much more money can we expect to earn in our webshop then?
→ Look at economy stats and calculate your business caseWhy is it some people do not complete their purchase today?
→ Look at user behavior analyticsIs the page we can come up with actually more simple to use than the multistep check out?
→ Make a GUI prototype and seeCan we make checking out in one page work with 3. party payment solutions?
→ Make a tech prototype and see
In that way discovery and research is not a blurry up front phase of “we need to know more about the users to make a better product” - instead it’s explicit tasks that can be considered and prioritised on equal terms with user stories in a backlog, to be done just in time (which is a core principle in agile you might remember).
Balance Discovery and Delivery
Opening up for bringing in random questions and research slots whenever in the process, can open up for a few discussions in the team how to spend our budget as wise as possible.
So, how do we decide how much effort we should spend on making sure we actually have a good way forward, before we execute on it and make the idea into a functioning solution that can produce value?
The answer is, it depends. But we have a few rules of thumb you need to consider:
Are we spending so much in making sure you have the right idea, so you can’t afford to realise it within your natural budget limit? Again, don’t invest more in something than what it’s possible worth to you.
How much damage can we make if we are wrong? E.g. if you risk losing a lot of users with your new feature, you can’t just roll back a bad decision.
Is rolling back easily done? E.g. sometimes changes require a whole chain of systems to change and a lot of people and timing involved, in that case it could be very pricey to roll back.
What is the time to market factor? Sometimes time to market is an important factor and can mean that you don’t have time to make all the research you would like to, you then just have to act on the information you already have.
Is the truth actually obtainable up front? Sometimes, it would sure be worth it if we had the answer up front, but there is no reasonable way to figure it out - other that to trying it out. E.g. would it be a better experience for our users to open list-items in a new browser tab? Best way forward is probably to try and see if it affects the bounce rate.
Do it tomorrow
You might think yeah right, in your dreams, my world is different.. And how we plan our processes is not up to me. The good thing here is that if you are involved somehow in digital development, you can still use the principles.
Map out your scope and make those implicit assumptions explicit, even if it’s still considered by others as a fixed “project scope”.
Make sure to ask questions/point out questionable assumptions, but come up with how to find an answer, and an estimate of how much effort it will take.
Help calculate the actual risk cost (or lost potential gain), if we don’t pick up on those questions and learnings.
A perfect solution?
At the end of the day, there will always be assumptions and uncertainty and we believe that the best way to handle that is to work in an explorative way instead of linear. Focus on which changes of behavior, you want to support and remember to always connect it to the business goals.
Make all the underlying assumptions explicit and by doing so, you empower the team to take ownership and responsibility for the end result.