Manage Learn to apply best practices and optimize your operations.

Software requirements: Taking development efforts into account

In this tip, SSQ contributor Matt Heusser talks about using "desirements dialogues," which include development estimates, to help the team get the best bang for their development buck.

We like to talk about software quality as if it's the absence of defects, but it's much more than that -- it's the presence of value. In this tip, I will talk about how to figure out the right things to build right now.

That said, I am not talking about a method.

At least, what I'm talking about doesn't feel like a traditional software development process. Instead of a handoff, where we do one step, pass to the next person who does the next, we'll want to interleave steps between two groups.

You might say that it's more like a dialogue.

The problem

Business people are usually pretty good at figuring out the value of what they want built; in some cases, they can even quantify the dollar value of the change.

They just don’t know what the change will cost.

Without understanding the value and the cost, we can't calculate return on investment (ROI). Without knowing ROI, we make poor decisions.

Imagine building the most cost-effective features for a project -- the very first few -- then releasing them. Then build the next few, and release them, until you have delivered 80% of the value for 20% of the effort.

Now think about how your organization currently decides what features should go in the next build.

I expect you see the problem too.

The Fix: Not requirements; Desirements

When we dream up things to build without respect to cost, it isn’t quite right to call them required -- especially the ones that don’t make the 80/20 cut.

After all, most projects are not binary; they could consist of a thousand different features that we could slice a thousand different ways. In order to decide what to build, the decision makers will want to take a few rough ideas, get some rough estimates, then pick the most promising, then develop them, slowly, over time.

If you can just assign an amount of effort to each feature, you can look at the work accomplished, the work remaining, and predict the ship date. With that knowledge, decision makers can take features out to hit the date, move the goal date to match predictions, or, just maybe, make the date earlier -- if the data suggests it.

To do that, we have to break out of handoff and get to dialogue.

From ideas to stories

One way to initiate the dialogue is to get every staff member into a room, then spend two weeks at a whiteboard, prototyping and estimating.

To make this work, you'll need to slice every feature into something small. I've seen a great deal of success trying to fit the stories themselves onto a single PowerPoint slide. Here's a simple story family:


Enlarge diagram.

You'll notice none of those stories are infrastructure, technical debt or "epics;" each one is carefully crafted to be between a half-day and week of two developers’ time, and designed so that it can be created and tested with a two-week sprint.

In order to get to these well-sliced stories, the technical staff and the product owners will need to work together. A team can do this at the white board, with the product owner describing a feature, the developers asking for examples, testers asking critical questions, and someone writing down a summary of the feature. It can be done in meetings for a “family” of stories, or in planning games, or, sometimes, distributed over time using a software tool. 

In addition to the plain text, each story has a code, like 'AB0104'; that's an identifier for the story in a formal system. The longer version might contain graphic designs, more clearly defined requirements, or acceptance criteria or "acceptance tests" the team agrees on up-front.

Finally, each story is of concrete, meaningful value to the end customer. There is no "research," "develop but not test," or "gather requirements" stories, though if the team is unable to estimate, it might be of some business value to create a spike, or proof-of-concept for a later story.

Once the team has stories defined, they need a way to 'point' them -- a way to assign relative work levels to each story.

Points represent ideal engineering effort or relative sizing; six points is twice as much as three points, and so on. When a team starts, four points might stand for a person-week, but vacations, sick days, holidays, team meetings, email, all conspire to make ideal estimates overly optimistic. Instead of trying to make the ideal time match actuals, most of the teams I've worked with abandon the ideal concept, simply comparing the work-effort to previous stories. We call this "relative sizing."

Estimating effort

When I started at Socialtext, we estimated each story in terms of points by a pair of programmers, and a different pair would do the work. Planning poker is another way to negotiate point values for stories. One team I work with walks around a large conference table, putting the stories in order of effort.

By putting point numbers on sticky-notes, then moving the stickies on the table directly below the stories, the team can indicate "all stories to the left are one point," "all stories between this card and the number one are two points," and so on.

Once the team has 'pointed' stories, product managers can pick the stories to work on based on a combination of value (what the product managers know) and cost (what the technical team just told them.)

It sounds easy, but all of this brings up some interesting problems.

Two common issues

  • The stories don't make any sense

The initial stories are likely to be of radically different sizes, lack clean 'seams' to know when they are complete, be hard to specify, and so on. I don't expect product managers to produce good requirements in a vacuum; instead, we've tried to get a few technical folks involved in figuring just what it is we are going to build, how to describe it, and how to know we are done. That means the initial meeting isn't an "estimating" meeting, as much as helping to collaboratively design the product and plan.

  • The two-week startup plan becomes irrelevant

You'd like to invest some time up-front and have something to show for it, like a completed backlog of stories and estimates. Sadly, I've never seen a story-driven plan survive six months; there is always some new requirement, or we failed to understand something. To fix this, instead of planning an epic, you might have an initial planning period of four days -- just enough to get the few several batches of stories lined up. After that, the team will create a new standing meeting at the beginning of every iteration -- a half day to discuss, design and point future stories. This way, the product owners are building the plan just-in-time.

Desirements in action

Clearly, this is not as easy as a simple, linear process where managers break up the work and the team just estimates it. Instead, this is a clarifying process, a refining process. We'll likely fail, or at least flail, a little bit along the way, especially at first.

Through this process we added a new variable to the mix: An understanding of cost. Once we factor in cost, we can track stories in a different order or discuss different implementation approaches which can have a radically different impact on productivity.

The key is to not start with requirements, but instead recognize that we are dealing with desirements.

Instead of handing off these piles of paper, we refine the ideas through dialogue.

Now that’s something to talk about.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.