2

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.

closed as too broad by BobDalgleish, Robert Harvey Apr 18 at 16:12

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    I don't understand this question. – Ewan Apr 17 at 13:02
  • Please feel free to ask any questions you may have, would be happy to elaborate on any vague parts. @Ewan – Azee Apr 17 at 13:57
  • "what would be the best representative for the issues which is going to be addressed by the team?" This doesn't seem to be grammatically correct? can you rephrase – Ewan Apr 17 at 14:07
  • "how the team is going to assign story points to those issues?" in the normal way i would guess? what is the perceived problem? – Ewan Apr 17 at 14:08
  • 1
    Dear BobDalgleish and Robert Harvey! I have edited my question to include only one question. Could you please reopen it, if it fits the community rules? – Azee Apr 24 at 7:11
3

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.

  • Regarding the estimates we are playing by the book, using poker planning. To my understanding it is a comparison based measurement. We used to use a base line to compare the complexity of the user story to determine its weight in regard to that base line. However, I am not sure if it is possible to compare a user story which leads to no code material (like a questionnaire in a survey engine) with those that leads to code. (our base line for comparison used to be of coding effort) – Azee Apr 18 at 3:39
  • It's possible with a useful enough level of accuracy. a simple 10 question survey isn't very complex, it's probably no different than updating some text on a page. A more complicated survey with branching questions, images, and videos my be more like a page redesign in complexity. – Ryathal Apr 18 at 12:26
1

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.