HANDLING THE UNKNOWNS OF YOUR PRODUCT

An important part in SCRUM is the idea to deliver value to the costumer early in the development of the products. By doing so enabling a feedback loop between costumer and development team. This is how we as a development team can learn what features that are most important and what the customer really wants. But we don’t always have all the answers in the beginning, let’s explore the way of handling this with the concept of spikes!

Three principles to think about regarding spikes are:

  • A higher level of ambiguity in a project will probably need more research based activities.
  • Specific questions is easier to answer precise in a short amount of time.
  • Spikes are not direct customer value, their purpose should be to enable us deliver customer value in or user story.

So, how do we proceed when things aren’t that straight forward, and defining user stories can somewhat ambiguous? When our life is easy the stories we define typical have characteristics such as that they are:

  • Independent
  • Valuable on their own
  • Possible to test and to demonstrate
  • Estimable.

But what if you and your team is stuck with questions such as:

  • Can we use this sensor to get reasonable data?
  • Is the response time fast enough?
  • Can the data channel handle the load?

or

  • How do a user use this feature?
  • Do I want to be able to configure this independently later?
  • Can we connect this sensor to the system?

Then it might be hard to define the extent of such a story?

When the uncertainty is high, there is a larger probability that we will waste resources. Either by developing something that is not worth the effort it would take, and hence not giving the customer a return on his or her investment. Or, having a team starting to develop a feature with too high ambiguity might end up in an endless discovery of ”an other thing that this also will depend on”, that will interrupt our flow as a team.

So, how can we handle this in the SCRUM framework?

A spike is a time-boxed exploring activity to enable us to define valuable user stories. It aims to research questions such as the once mentioned above. A spike is the pure R, in R&D and with its fixed duration, the risk of time, just drifting away is minimized. And if the results demonstrated after the spike is not enough, the lets iterate a new question in a second Spike! 

Caption: The purpose of doing activities such as spikes is to widen our known into the known unknown. If we then also happen to know more about our unknown unknown we celebrate it as a nice side effect of our spike!

Coming back to customer value, is a Spike really customer value?

I would say no, it is not direct customer value. But it is indirect customer value. The value of research is one level more abstract than the value in development, because it is not part of the product we ship. But customer value is not to deliver as many lines of code as possible, it is about deliver the right lines of code. This is also why evaluating development team with velocity can be a risk.

“One is never afraid of the unknown; one is afraid of the known coming to an end.” – Jiddu Krishnamurti