Month: February 2017

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

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.

Diagrams

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