Is your backlog still relevant?

 photo loading-652297_1280_zpsmlmpdbv8.jpg

Requirements management is a problem for all fields. It is particularly hard in software where the end product is “soft”.

We have already discussed the dangers of going overboard with scoping and how to work with user stories for more concise and agile requirements. A user story simultaneously deals with the problem of over and underspecification elegantly.

A collection of user stories is organized into a backlog. We have already seen how a backlog looks like

Mike Cohn describes a backlog simply as:

    A prioritized features list, containing short descriptions of all functionality desired in the product.

The short description he is talking about is of course a user story.

Once your initial backlog is written out, your task as the scrum master is to ensure that it remains a valuable asset to the team and not left to atrophy and finally abandoned.

In this entry we shall be looking at some of the questions that you can ask yourself to gauge the health of your backlog.

Is the backlog prioritised?

Scrum is based on the belief that you deliver most value by working first on stories that have the most value to the customer. This is achieved by ensuring all stories are prioritized.

Most teams are disciplined enough to do this the first time the backlog is written. Over time, the order is lost as more stories are added or as change happens and other stories suddenly become more important. This by itself is not a problem, the problem is that the change in priority is not reflected in the backlog.

If this continues long enough, the client then loses faith in the backlog as a tool to express what is important to them.

Is the backlog and its stories easily changeable?

Scrum has no hard specifications on how the backlog will be encoded. It does however have a preference towards a paper based system, only because this kinds are the easiest to change. If a story is no longer useful simply rip it up.

Easily changeable here will depend a lot on context. Putting up your user stories in the middle of say a product strategy document is likely to introduce a lot of drag. Who wants to go through a monstrous document just to change one sentence?

Requiring multiple authorization levels to make changes is also likely to cause the same problem. Rather than go through the hustle of asking for permission, the team member who has noted the change would rather not document it.

Finally using an unnecessarily complex tool is likely to discourage any kind of engagement with it. We all have too much to deal with in our life, taking the time to master a new tool is just not likely to get done.

At this point I must emphasize that change still happens whether your tool accommodates it or not. In the unfortunate case that it does not then it becomes obsolete.

Are the stories estimated?

Estimates are incredibly important to any story and the resulting backlog. Typically estimates are given in story points. A story point is an arbitrary measure of effort required to implement a user story.

By its nature, story point estimation forces you to triangulate story size and have heated discussions with other team members so as to come up with an agreed upon estimate. This process then helps destroy any illusions of agreement that may exist and build alignment.

Eg if there is a story such as “As a new customer I want to be able to register using either my phone number or email” and the developer gives an estimate of 8 while the client gives an estimate of 1. A discussion can ensue upon which the client can understand why this is a hard feature to build and maybe rework it or the developer can see where she misunderstood the client.

Hence, a backlog that lacks this estimates and the discussions associated with them is likely to drift away from the client’s dream both in terms of scope and delivery time.

Are the stories detailed appropriately?

A common mistake I see is teams specifying to great detail work to be done in months or even years time.

Prudent as it may seem, you are likely guessing what is going to happen. Complex systems necessarily arise out of adaptive processes. By the time the months lapse, your story will probably be invalid.

Unfortunately, even when we discover that the story that was written months ago is no longer relevant, if enough effort was put into crafting it, then we will feel guilty about abandoning all that work. Thus the work will continue to stay on the backlog with no chance of ever getting done creating a drag on everyone’s psyche.

How do you keep your backlog relevant? Talk to me in the comment section below or on my twitter @jchex


Working with minimum specifications

 photo lost-places-1838041_1280_zpskc08gujf.jpg

In a previous entry, we took a look at the dangers of over specification.

Over specification is simply where the client not only tells the developers what needs to be done in great detail but also how and when.

We now know this is not a good strategy for building your products, but then what is?

You guessed it, minimal specification!

A minimal specification consists of the minimal amount of information needed to meaningfully specify the product.

Let us go right ahead and look at some of the tools available to us to employ this methodology.

User stories

We have already discussed at length what user stories are in invest in user stories.

In the world of software, user stories are the best thing since sliced bread, maybe even better.

A user story follows the format:

As a [persona]

I want to [do something]

so that I can [derive some value]

This very simple format conveys deep meaning. When well done, everyone understands what value they are offering and to who. This has the virtuous effect of providing a rich backdrop for conversations between developers and clients to take place.

Also, because of its concise nature, there is far less attachment. Which means that if the requirement is no longer valid, it can just be torn up and a new one written up.


We use words so much in our daily lives that at times we forget that they have no real existence, they only point towards concepts.

    Truth has nothing to do with words. Truth can be likened to the bright moon in the sky. Words, in this case, can be likened to a finger. The finger can point to the moon's location. However, the finger is not the moon. To look at the moon, it is necessary to gaze beyond the finger, right?
    ~ Buddhist saying

Words then create a new layer of abstraction over the requirement that is being conveyed.

To mitigate this effect, get down and dirty with the work. Have the client draw what it is they want, they can sketch out the UI views or even mind map how their ideas connect. Do everything you can to break down illusions of agreement.

At iHub, we use pidoco a wireframing tool that anyone can learn to use within minutes. This may be useful for you too if say your clients are remote.

Delegate decisions to developers

Developers routinely resolve ambiguities in requirements before it even bubbles up to the client’s consciousness.

  • Will we use InnoDB or MyISAM for our DB?
  • Will we first register the use on our newsletter and then send them a welcome email or the reverse?

In a day, such decisions may number in the hundreds. It would simply not be practical to have all of them conveyed first to the client for resolution. Yet as is the nature of our work, a few of those decisions will come to the attention of the client and they may not like the path taken by the developers. In such cases, it is important that the impact of reversing the decision be weighed down soberly.

In this way, development can proceed fast with decisions leaning on “What and Why are we building?” being made by the client and the question of “How are we going to build it?” being made by the development team.

What is your theme?

Almost everything is noise. This simple heuristic applies to everything from the candidates who have applied to a posted position to the tweets showing up on your timeline.

The Pareto principle states that, for many events, roughly 80% of the effects come from 20% of the causes. This law applies to requirements just as much as it applies to land ownership where 80% of the land is owned by 20% of the people or business where 80% of a company’s profits come from 20% of its customers.

In the same way, only 20% of the requirements are going to provide 80% of the value to the customer. You must then focus on this 20%.

A theme provides an easy and intuitive way to do so. They map out the landscape upon which decisions are made.

For example, if the theme of our product is “make it as easy to use as possible”, then a requirement that provides sophisticated ways of modifying the behaviour of the product is de-prioritized.

A theme then gives meaning to minimal specifications by providing them with context. This also has a nice side effect of providing a toe-hold for new team members to understand what the project is all about.

Do you use any minimal specification techniques in your own projects? Talk to me in the comment section below or on my twitter @ jchex


Dangers of overspecification

 photo folding-rule-705668_1280_zps1zwo3f8q.jpg

Software projects tend to be expensive endeavours. With average salary for a single senior engineer topping USD 100,000/year an engineering project just maybe the most expensive engagement that the client has had to make.

It is no wonder then that the client would like to derisk the project as much as possible. The most obvious route to this outcome is to specify in great detail what it is that you want.

As a client you can then go wild specifying exactly how the screens will look like. Design flow diagrams, state diagrams, UML diagrams and just about any other diagram you can Google.

What you may not understand is that by over specifying the technical details you put your project in more jeopardy. To understand why, let us look at a classical engineering problem.

In the earlier days of the elevator business, Lift companies faced a barrage of complaints from their users on the lifts being too slow. The most obvious way of solving this problem would be to splurge on research to find out how to make the lifts faster and then spend further in development to bring the insights to life.

Thankfully an engineer identified the real problem. The issue had nothing to do with the speed of the lift but rather the perception of slowness. In short people were bored. The ingenious solution, install mirrors. This was a perfect solution, cheap to install, could be retrofitted into existing designs and the riders loved the chance to explore their vanity!

At iHub we run projects through a design sprint. The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.

The design sprint helps answer the question, are we building the right product?

This sprint has proven to be the one with the highest ROI. Not because any software is built to handle the problem but because the team consisting of the developers and the client work on problem identification.

When a client walks in and hands the technical team a detailed specification document, the implicit assumption is that they know the problem and they have the solution for it. This assumption is woefully wrong.

What if it’s not, what if the Business Analysts from the client’s side actually have it nailed. Is all that remains simply for the developers to knock it off?

Unfortunately no. Change is the only constant. As the product gets developed and the idea moves from the more abstract realms, new requirements are guaranteed to arise. This changes will then become a monster of a political problem. A lot of work by a lot of people goes into writing out a detailed spec document. Changes to the document imply that somehow the authors were wrong.

People will more strongly cling to their ideas in the face of contrary evidence. The phenomenon is so well known, psychologists have a name for it Confirmation bias This human factor is almost certainly going to run your project to the ground.

Yet even if the project was somehow able to escape all the previous pitfalls, over specification tends to make the project more expensive than it needs to be. Specifying too much detail at the beginnning of the project means that you can not use commercially available software. While the third party option may not look exactly the way you envisioned it, it just might be able to deliver all that was required of it without much hustle. The economics of buying over building have been proven, let them work for you.

Finally, even well meaning clients may just lack technical insight into their own problem. A spec document in this case is then thinly veiled software design. Software architecture is a field in its own right, practitioners of it have earned their stripes from tens or even hundreds of projects before this one. Do you really want to dismiss all this experience?

How do you handle over specification within your own projects? Talk to me in the comment section below or on my twitter @jchex