Skip to main content

Just In Time Software Requirements: Introducing "Value Spikes"

I've been pondering further difficulties of being a product owner, both silently and aloud, so yesterday I was happily bowled over by a new idea on the topic from my new ThoughtWorks colleague Jasper "Dutch" Steutel (@dutchdutchdutch for twitterphiles).  He calls his discovery the "design spike," and we ended up talking together about a related concept, the "value spike."  So what's this all about?  Aside from being "Vampire Month" on the Pragmatic Agilist?


The Problem

It may be different in a small start-up or a firm well-organized into small, highly integrated business/technology verticals, but in a typical large corporate enterprise with matrixed silos, it is quite challenging for a Product Owner to speak for all of the stakeholders on a project.
  • The PO must be able to speak fluently to the technical people on the team
  • The PO must be able to provide one reliable set of priorities which reflect acquiescence among all of the PO's horizontal peers in the organization, plus their direct reports.  If there are competing priorities among those peers, creating and maintaining this uber-backlog will involve some serious facilitation chops.
  • The PO must also be able to speak authoritatively within the funding hierarchy and hierarchies in which the project finds itself.  The "funding authority" is likely an executive with her own relationships to maintain.
  • The PO should also be a user of the software and be able to speak to the full user experience; the PO should be able to conduct UAT.
  • While they're thus occupied, POs must also be steadily (if not continuously) available to the team. 
Moreover, on teams that believe there should be life for a project before iteration 1, the PO somehow has to make all of this happen at a high level during a quick 2-4 week "inception" period, and then keep the team in touch with the right subject matter experts as the project proceeds.  How can any one person actually do all this?


For those of you who aren't already familiar, a "spike" or "tracer bullet" is a short piece of work within an agile project in which one or two programmers may be assigned to do outside of the iteration structure.  The spike investigates unknown technology problems well enough so you can estimate them.  There's a nice explanation in this blog post about these related concepts and their origins.

An example would be that the team discovers it needs to use a new visualization technology for a planned dashboard, but nobody on the team has ever used the technology before.  So the team simply doesn't know how long the work will take related to that new technology.  At the point where the team urgently needs to know the details about how hard it is to work with the new technology, the group agrees to send a pair of programmers off for a pre-specified amount of time (a "time box") to learn enough about the new technology so that the project work can be estimated.

Any work the programmers do in this spike typically will be thrown away--the spike produces team learning, not reusable software.  Once you know how long the tasks related to the new technology are going to take, you can make appropriate decisions about what to include and what to postpone from your current planned release, compared to other features which have already been estimated.  You adjust the backlog accordingly, and the team moves forward.  Conceptually:

Spike allows for backlog adjustments based on needed new information.  But note that no new working software has been written during the spike.  The output of the spike is just learning.

Design Spikes
Dutch, who has brought many years of product management experience to ThoughtWorks, points out that on a product-oriented team, you may be as likely to need a "design spike" as a "technology spike" before you can complete backlog grooming, or even complete a story that is currently in play in an iteration.

In this case, the developers may or may not know how to write the software behind the story, but what is very clear as you talk it through in the team room is that nobody knows what the desired user experience should be for the software.  What do you do?  You take the story out of play for the current iteration, and hold a workshop for the PO and any SMEs who can speak for customers, or even customers themselves, and determine what the user experience should be.  This could be expressed as a wireframe or a photograph of a white board--unless the question is specific to the design at the CSS level, you may find it more helpful to come out of the design spike with team learning about the desired user experience, not a complete web page template.

Note that in an idealized "Continuous Delivery" project, every iteration actually calls for a software implementation of a design spike, and so-called A/B user testing determines what your next step should be by measuring the way actual customers use the software.  Notice what happens here--if you're working with known technology, you may do an entire project without doing a software spike, in the standard sense of the word.  Even though some of the software gets thrown away, you're always building the real software, not a throw-away architecture.  But from a design perspective, continuous delivery is nothing but a set of design spikes which result in team learning, and throw off the software itself as a side-effect.

Value Spikes

So let's take the spike concept back to the poor, overworked Product Owner stuck doing a vendor workflow implementation for internal use at a very large company.  This thing is not being ported to an iPad any time soon.

The team is all sitting around in the team room talking about the new dashboard you're implementing in this sprint.  As it happens, the developers are not familiar with the visualization technology, and they are eager to go off and have a spike to figure it out.  And goodness knows they deserve it--all they do is write integration code all day long.  But wait--before two lucky programmers run off to play with something new, it turns out that the team stops to ask the Product Owner what the value of this dashboard is going to be.  It seems like a lot of architectural investigation for a product that is going to use 3D to visualize work orders going from the "pending" state to the "done" state.  Why, you ask, is 3D necessary for this?  What is the value?

Most likely the Product Owner does not know, in this environment, how the team ended up with a request for a 3D workflow state change visualizer.  There are a lot of players, and there's a lot of politics, and it's a big project, and this is only one of a thousand requested features.

This is where the "value spike" comes in.  Just as you should stop work to get a general idea of the effort involved in specific stories, or the user experience required, you should also stop work to allow the Product Owner a time box to assemble the right SMEs for a meeting to determine the authorship and impact of a requirement whose value seems questionable.  The PO does not have this information top of mind any more than the developer has information on every possible technology ready to hand.

In this case, the PO will return within the time box with a fresh view of the value of the feature, and just as happens with a technology spike, the PO will do a new cost/benefit analysis based on the value the feature will bring compared to the cost it will take to develop it, and modify the project backlog accordingly.  It looks like this:

Seem familiar?

In case the suspense is killing you, in our hypothetical case we'll stipulate that the Managing Director who staffs the data entry area has trouble understanding why things are so slow.  The project sponsor, manager of these data entry people, has made it her top priority to make the staffing problem crystal clear.  She would implement "Smellovision" if it were possible.  This feature jumps to the front of the backlog, the team completes it, the sponsor is happy, and everyone has a good day.

Design and value spikes should be tactics that every Product Owner keeps handy.  You don't have to be omnipotent if you have a technique that lets you become expert on one little piece at a time.  And that's as close as we get to Enterprise Fun these days.


  1. Hi Elena
    I like your Problem statement for the PO and
    I get the Design spike, but I am not clear about the Value spike. Are you saying that the team stops everything and waits for the PO to come back with confirmation of value and a modified backlog, or that just the 3D feature story is put on hold and other stories are worked on as some sort of dashboard is needed anyway? Doesn't the change of backlog depend on the cost benefit analysis which in turns requires the team to spike the technology to get a reasonable estimate, so shouldn't that happen anyway? If the overworked PO has missed understanding the benefit or value of a feature before putting it to the team then the long term solution would be to scale up the PO function in the customer team to reduce these errors rather than relying on spikes as part of the process?

  2. Hi Ian,

    Thanks for asking! I probably shouldn't have chosen an example in which both a technical spike and a value spike would be needed. You are right--in this example, both would be needed. But the point I was hoping to make is that even if the technology were known, the value spike would still be needed, and not to determine screen behavior--just to determine value.

    My feeling is that the business environment is as prone to require an occasional spike as the technical one, either because things are changing in the market, or because more depth of analysis is needed.

    In other words, for a cost/benefit analysis, we should allow for spiking on the benefit as well as on the cost. To keep it agile, we should embrace change from the value side just as we do on the technology side.

    From that perspective, I don't regard changes in business value to be "mistakes." My idea was that the value spike would indeed be a technique to take on which would allow for as-needed scaling of PO capabilities.

    Makes more sense?


Post a Comment

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

How To Write A One-Page Proposal to an Executive

One day you may need to communicate with an executive. Pro tip 1:  executives do not have time for you to dim the lights and show them forty slides with charts composed of animated dancing leprechauns and flashing arrows that emerge from the void in a checkerboard pattern. Pro tip 2:   Guys, and gals with deep voices, executives also don't need you to use your "Radio Announcer Voice."

As a rule, what executives want is simple: one printed page. No matter what it is, it should be one page. And it should be printed, not emailed.  You should plan to hand it to the executive, and then you should be quiet when they read it and wait for their questions.  It's harder than it sounds.
 So how do you do it?  Here are the steps:
Write the deck that expresses your proposal in as many slides as it takes.  Use imaginative animation and blinking letters if you must.Remove your title slide.Insert a new slide at the front of the deck with "Appendix" written on it in big …