Assigning story points to the hypothesis in the backlog [closed]

Question

We have been using Scrum as our project management platform for a while, now we are moving toward Lean UX and hypothesis driven development practices. We are using Poker planning to determine the effort needed to deliver the outcome.

We have decided to use Barry O'reily's proposition of including both user stories and hypothesis in our backlog and based on Lean UX proposed approach by Jeff Gothelf all the efforts are going to be handled through the development team effort. In order to do that we need to be able to assign a story point to hypothesis as well.

Given that Poker planning is a comparison based measurement, what would be the right approach to assign story points to the hypothesis effort?

P.S. Based on what we learned from Lean concepts we are determined to move all the development efforts into our sprints, moreover, we are open to any ideas related to "#NoEstimates" movement.

Answer 1

There is nothing about story points or scrum that makes assigning story points to something impossible or even difficult, unless you have massively altered the definitions within your own process. Story points are an estimate based on complexity, with only a vague relation to time. In most times story points eventually become more time based which makes assigning them to any arbitrary story or issue easier. Second, there is the misunderstanding of what is meant by a sprint being able to deliver a shippable product at the end of every sprint. Stories and sprints are intended to deliver units of value to the product owner, this is commonly misinterpreted as working code for every story. In the case of hypothesis driven development the yes or no is the valuable part, stories should work towards how to get that yes/no, and what to do with a yes/no. There isn't a need to write or estimate stories to fully develop and implement a hypothesis until you've tested it, and at that point you should have sufficient insight to deliver reasonable estimates. It's even possible and useful to have stories that have an output of other stories.

It sounds like you are in a common pitfall of having a separate requirements gathering, getting a bunch of things written up, and now trying to throw it over the wall to the development team. This is a waterfall mentality that is hard to break, a preferable alternative is to have stories that involve parts of your development team to help take the idea and turn it into stories and requirements. If you already have a lot of things the best solution is to write it up in a logical story breakdown (as a first pass) and use some backlog grooming time to restructure and flesh out the initial stories.

As for how a product owner would prioritize these items, it becomes straightforward once they get written up as features/epics/stories. It becomes a simple question of is knowing if hypothesis A is worth pursuing is more or less important than new feature B or bug fix C. If hypothesis D is a complete unknown on how hard designing an following a test will be, then make a story to find out and prioritize that. Adding "what do I want to know" to sprint planning processes can be a helpful way to get a lot of valuable user stories that aren't really development work, but are often more useful.

Answer 2

I am not an expert on hypothesis-driven development, but have some knowledge of it. Here are a few things I would consider:

1. The full realization of a hypothesis may take varying amounts of time. This may be problematic in a timebox of sprints where the work may be done but the experiment needs time to prove out. Of course, we can mitigate this with small experiments and with truly continuous deployment cycles, but it's at least a risk to acknowledge.

2. The process is inherently open-ended. You don't know you are done with the work until the condition is met. Let's say you have an item that "We believe that reducing the complexity of the sign-in form will make it less daunting and increase the rate of sign-up completion. We will know it succeeded if the completion rate of started signups increases from 10% to 30%." Now you do the work and over the next period it increases to 23%. You made positive progress, but you didn't quite get there. Do you call it good enough? Do you go back and simplify the process more to see if you can get that last 7%? This is a conversation that your teams and organizations will have to get very good at.

3. As with any open-ended item, there is a risk that you keep pouring work into it without getting benefit. Practices like Spikes in XP have this same problem and they address it with task-based timeboxes instead of points. A task-based timebox really just defines how long we're willing to spend on a particular problem before we should regroup and decide if it's really worth spending more time. So, if you use the example I gave above, we might decide that we are definitely ok spending 16 hours simplifying the page. After that, we want to look at the results and see if it's worth spending more time.

4. A final thought: don't over-commit yourself to just one way of framing work. The idea of hypothesis-driven development is really powerful. So are user stories. So are many other ways of working. Every team I worked with was better off for choosing the framing that best fit that particular effort rather than sticking to only one approach.