Let's face it. There is no perfect solution. No perfect solution for humans to share information accurately, consistently between multiple people, and over a prolonged period of time.

Especially when you add into that equation the level of detail that's needed to capture the requirements for a major software application.

And then there's the complexity of software. And the fact it's plyable. Its evolutionary nature means it simply isn't comparable to the creation of many other products. And certainly not comparable to construction projects, where once built the requirements are literally fixed in stone.

Software requirements, therefore, are a uniquely challenging communication problem. Such a challenging problem, we mustn't kid ourselves into thinking there's a solution. Personally, I am pretty sure there is not.

However, there are ways of mitigating some of the problems, whether it's in written or verbal form. Let's look at some of the pros and cons of each...

Written Requirements
–can be well thought through, reviewed and edited
–provide a permanent record
–are more easily share with groups of people
But, are:
–time consuming to produce
–may be less relevant or superseded over time
–can be easily misinterpreted

Verbal Requirements
–provide opportunity for instantaneous feedback and clarification
–are an information-packed exchange
–can be easier to clarify and gain common understanding
–are more easily adapted to any new information known at the time
–can spark ideas about problems and opportunities
But:
–are spur-of-the-moment and not always well thought through
–are harder to share across groups of people, particularly if not co-located
–conversations can be remembered differently by different people

Whichever form of requirements capture you prefer, we must all remember the old addage: "A picture is worth a thousand words". It's so true. Whether it's a diagram in a spec, or a sketch on a whiteboard, pictures add a dimension that is immensely valuable.

The approach of User Stories seeks to combine the strengths of written and verbal communication, supported by a picture where possible. See here for an example of a User Story Card.

And some key principles of agile development seek to address some of the weaknesses of both forms of communication, in an effort to create a best of both worlds:

• Active user involvement to ensure continuous visibility and feedback
• Agile teams must be empowered to make decisions, so details can be clarified at the time of development
• An acceptance that requirements emerge and evolve as the software is developed
• Agile requirements are 'barely sufficient', so they are not too onerous to produce and the latest information can be incorporated at the time of development
• Requirements are developed in small bite-sized pieces, so details can be captured verbally whilst minimising the risks of people forgetting details or not being involved when the requirements are developed
• Enough's enough - apply the 80/20 rule; capturing every detail isn't necessary to produce a quality product; verbal clarification, visible software and feedback works better
• Cooperation, collaboration and communication is essential between all team members, as everyone involved must know the outcome of any discussions about requirements.

read more

When putting User Stories onto a Product Backlog (or feature list), you shouldn't feel compelled to break everything down until the features are nearing development.

Further down the Product Backlog, it's fine for items to be fairly fuzzy. It's also fine for items further down the backlog to be whole projects - large, high-level items that are not so much User Stories but more like Epics!

As an item nears development, the item should be broken down further. And as it nears development, the item on the backlog should be defined in sufficient detail that the team can reasonably estimate its size and break it into tasks.

Until that time, however, it's just really a placeholder. A reminder for prioritisation and high-level estimating. That's all.

For some people, particularly those used to a more traditional project approach, used to detailed specifications up-front, this can potentially feel very uncomfortable. It shouldn't.

The logic here is simple. There is little point defining a feature (or set of features) in detail if it may never reach the top of the priorities. The other aspect of this logic is that you tend to know more about your requirements, constraints, etc as time goes by.

And things change. People come and go. Sometimes the team has changed significantly since the original requirements emerged, so information can be lost if it is captured too early.

Therefore it makes business sense to defer details until they are needed.

read more

I recently described User Stories and the composition of a User Story Card - Card, Conversation and Confirmation.

I'm not really sure if you would consider this example to be good, bad or indifferent - I guess it depends what you're used to - but here is an example nevertheless!

This is the front of the card.

The Card section describes the user story. The Conversation section provides more information about the feature.

Note the feature (for a user to log in to a web site) is small, so the story can be fairly well described on a small card.

Clearly it's not as detailed as a traditional specification, but annotating a visual representation of a small feature at a time, makes it fairly self explanatory for team members.

And I would certainly argue it's more easily digestable than a lengthy specification, especially for business colleagues.

Here is the back of the card:

The back of the card outlines the test cases for this feature - how it's going to be confirmed.

Whether or not these are the right scenarios, or cover all possible scenarios, isn't really the point of this example.

The point is that the test cases for this feature are written on the back of the card, in support of the information about the feature, and before the feature is developed.

Generally speaking, there is a very fine line between a requirements scenario and a test case, so it isn't necessary to capture too much detail on the front of the card and clutter it up. The card in its entirety represents the requirements for the feature; whether captured in the Conversation section or the Confirmation section.

Even the description of the user story in the Card section carries some important information. In this case, there is a pre-condition (the user must be registered) and a post-condition (the user can access subscriber-only content). All of the card must be read to get the whole story.

Importantly, the User Story is expressed in business language, and in a micro, more easily digestable, information-packed format.

read more

If you're capturing user requirements using User Stories, write them on a postcard... (a blank one of course!).

A User Story Card should ideally comprise 3 parts: Card, Conversation and Confirmation...

Card
The heading section of the card should include the name/description of the user story, any reference numbers, estimated size, etc.

Conversation
Most of the front of the card should include further information about the user story and what the software is meant to do. This can be a sketch or diagram of the feature, or notes about how it should function. Anything that helps to concisely explain the feature. Remember this is a reminder of the story and notes about it, not a full specification on a card. The team should collaborate to get more details at the time of development.

Confirmation
Write test cases on the back of the card. Writing tests up-front helps to ensure the software is designed to pass. Writing tests up-front also helps to identify scenarios that users, developers and/or analysts may not have thought of.

Keeping User Stories small enough to fit on a card helps to ensure that requirements are broken into small, manageable pieces of functionality, i.e. individual features.

Cards also work nicely in conjunction with whiteboards, providing clear visibility of progress and enabling team collaboration, moving cards around the board as things progress.

read more

User Stories are a simple way of capturing user requirements throughout a project - an alternative to writing lengthy requirements specifications all up-front.

User Stories are derived from XP (extreme programming), however they can just as easily be used for requirements gathering in any agile development methodology, or indeed in any home-grown development process.

A User Story is a simple statement about what a user wants to do with a feature of the software, written from a user's perspective. A User Story should not use technical jargon or state design goals. User Stories should be written in business language that is understandable to all.

A User Story should focus on the who, what and why of a feature, not how.

For example, on a job site, two high-level User Stories might be:

• As a job seeker, I want to search for a job, so I can advance my career.
• As a recruiter, I want to post a job vacancy, so I can find a new team member.

This is a useful construct to give a consistent shape to User Stories, and to act as a constant reminder to focus on who, what and why:

As a [user role], I want to [goal], so I can [reason].

Some people may consider the third part of the construct to be unnecessary. However I think it's good to state the user's motivation for using the feature, because:

(a) it gives clarity as to why a feauture is useful;
(b) it can influence how a feature should function;
(c) it can give you ideas for other useful features that support the user's goals.

At the start of a project, capture an initial list of User Stories up-front. In Scrum this would be the initial Product Backlog. This feature list is useful for estimating and planning. But defer capturing the details until the story is prioritised and due to be developed in the next Sprint or iteration.

In meetings with users (or user representatives), users will often tell stories about the failings of their current system or process. Or they might tell stories about how they see things working better in future. Try capturing these stories as User Stories. On cards. While you're in the meeting. As they are told.

In traditional development projects, these stories often aren't captured as they are told, they're captured in a lengthy analysis process and captured in a lengthy document; a format that isn't particularly user friendly.

Using User Stories, you might be surprised just how easy it is to leave a meeting with users, with their key requirements already captured.

read more

In step 1 - my first article in this series - I described 'how to get your backlog in order'.

If you've completed step 1, congratulations! Because it's the biggest step. And the foundation for all else that follows. Whether or not you implement Scrum.

If you haven't completed step 1, you must not go any further until you have.

So here's Step #2: How to estimate your Product Backlog...

High Level Estimates

You need to provide some high-level initial estimates, in order to get an idea of the size of your product backlog items.

This is helpful because it helps to inform the decision about priorities. And whether or not the features are likely to be worthwhile. And from a management point of view, gives a perspective of how big the team ought to be, commercials permitting.

But as yet, you don't know much about the items on the backlog. You don't know exactly what the features are meant to do. You don't know what tasks are needed to complete them. And you don't really know how you will implement them.

So you have to do a very high level, top down, indicative estimate. In fact it's a guestimate. Not an estimate at all really.

How many times have you heard someone say, 'don't worry, I won't hold you to it; I just need a rough idea'? And of course they do hold you to it. Of course they do!

Estimate Product Backlog in Points

The answer: Estimate your product backlog in points. Not in units of time.

Repeat: Estimate your product backlog in points, not in units of time.

No, I haven't gone mad. I know it sounds a bit whacky. But I'm going to ask you to trust me on this one; it does have its reasons, some of which will only become clear later in the series.

In the meantime, I ask you to accept that development teams are more readily able to give guestimates of 'size', without giving an estimate in time that they might be held to, and without having all the gory details.

So we're not asking the team 'how long will it take?'. We're asking 'how big is it?'

I also ask you to accept that Product Owners are more inclined to take this as a guestimate - as it's intended - and not as a premature commitment.

Now I realise that points could be seen as useless to a Product Owner in terms of making a business case for funding. Certainly until a team has a track record and we know roughly how many points they tend to deliver in an iteration. But I'll come to that later. Certainly, it is still helpful for prioritisation and to get across the relative size of a feature to a Product Owner.

Use a Points System

So what scale should you use for your points system?

Personally I like Fibonacci numbers.

For clever people, click on the link above to understand what Fibonacci numbers are all about. For simpler people like me :-) they're basically a sequence of numbers that some very old and very clever people (generally Italian, as per usual) have worked out have a slightly spooky, but very scientific significance. And this significance all relates to physics and the laws of distribution.

More about Fibonacci is really beyond the scope of this article, but they are a scientifically significant set of numbers, where each number is the sum of the previous two. They are:

1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987 ...

For the sake of simplicity, when using these numbers for indicating size, I would suggest you use the range 1-21. Certainly for bug fixes and enhancements on products in the BAU (Business As Usual) cycle, this should give you sufficient a range. Maybe reserve 987 for that daft request you get sometimes to fly to the moon and back in an ice-cream carton :-)

The key here is about relativity.

A backlog item describes a feature. Maybe, for example, it's a report. You've done similar reports before, but it does have some complexity in the underlying data, so you decide to call this a 3.

Next on the backlog is another report. You size this one relative to the other one. Is it bigger or smaller. Clearly 21 is a lot bigger. 2 is a bit smaller. And so on.

To make sure the scale works for you, I suggest you start by picking what you think is the smallest thing on the backlog. Give this a 1. Then find the thing you think is the biggest thing on the backlog. Give this a 21.

Now you have your markers, size the backlog, working from the top, using the Fibonacci numbers.

When you get further down the backlog, you'll get to a point where the items are really rather fuzzy. And rather low priority. In fact you not sure you'll ever get to them in your lifetime. Please don't feel you have to size the entire backlog. Size enough of the items to see you through the foreseeable future. Remember it's already been put in priority order. So make sure you work from the top.

Estimate as a Team

Size your backlog as a team. There's a whole philosophy about the Wisdom of Crowds. Two minds are better than one, etc, etc. If there are big differences, use this as a discussion point to understand why. Did one person see issues and complications the other person didn't? Did one person see a nice simple approach that others didn't?

Consider playing Planning Poker. This is a fun technique to ensure that people don't influence each other. Each team member writes their estimate on a card, and everyone shows their answer at the same time. It helps to ensure less experienced members of the team are equally engaged and are not over-influenced by more experienced team members. It also helps less experienced estimators to learn from others. And it helps to avoid stronger, more vocal characters having too over-bearing an influence on the result.

From this exercise, negotiate the size of each backlog item as a team.

Review Priorities

Once you've sized up the backlog - or enough of it - ask the Product Owner to have another quick look at priorities. Maybe now they can see the relative size of the features they've asked for, they might change their view of priorities. 'Wow, if that's a 21, I'd rather have the other stuff first', or 'if that's only a 2, let's get it in the next release'. If any priorities are changed, simply move the item's position in the order of the backlog.

Stick with the Programme

Resist the urge to adapt this step. Ken Schwaber's book 'Agile Software Development with Scrum', which is highly recommended by the way, says this: If you are not yet an expert in a subject matter (e.g. Scrum) do not attempt to adapt it. Scrum is an adaptive process. But you are in no position to adapt it until you know it well, and have experienced it in operation.

Sizing up your backlog using points in one thing I would encourage you not to adapt until you've tried it, and tried it over a period of several Sprints so you can start to see the effects.

Next in the series: Step #3: Sprint Planning/Requirements

Follow this series by email

See also:
How to implement Scrum in 10 easy steps:
- Step #1: Get your backlog in order!
- Step #2: How to estimate your product backlog
- Step #3: Sprint Planning/clarify requirements
- Step #4: Sprint Planning/estimate tasks
- Step #5: Create a collaborative workspace
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #9: Finish when you said you would
- Step #10: Review, reflect, repeat...

'Implementing Scrum' PowerPoint Presentation

10 Key Principles of Agile Software Development

read more

Agile Development teams capture requirements at a high level and on a piecemeal basis, just-in-time for each feature to be developed.

Agile requirements are ideally visual and should be barely sufficient, i.e. the absolute minimum required to enable development and testing to proceed with reasonable efficiency. The rationale for this is to minimise the time spent on anything that doesn’t actually form part of the end product.

Agile Development can be mistaken by some as meaning there’s no process; you just make things up as you go along – in other words, JFDI! That approach is not so much Agile but Fragile!

Although Agile Development is much more flexible than more traditional development methodologies, Agile Development does nevertheless have quite a bit of rigour and is based on the fairly structured approach of lean manufacturing as pioneered by Toyota.

I personally believe Agile Development teams can build better products if they have a reasonably clear idea of the overall requirements before setting out on development, so that incorrect design decisions don’t lead the team down dead ends and also so a sensible investment case can be made to get the project funded.

However any requirements captured at the outset should be captured at a high level and in a visual format, perhaps for example as a storyboard of the user interface. At this stage, requirements should be understood enough to determine the outline scope of the product and produce high level budgetary estimates and no more.

Ideally, Agile Development teams capture these high level requirements in workshops, working together in a highly collaborative way so that all team members understand the requirements as well as each other. It is not necessarily the remit of one person, like the Business Analyst in more traditional projects, to gather the requirements independently and write them all down; it’s a joint activity of the team that allows everyone to contribute, challenge and understand what’s needed. And just as importantly, why.

XP (eXtreme Programming) breaks requirements down into small bite-size pieces called User Stories. These are fundamentally similar to Use Cases but are lightweight and more simplistic in their nature.

An Agile Development team (including a key user or product owner from the business) visualises requirements in whiteboarding sessions and creates storyboards (sequences of screen shots, visuals, sketches or wireframes) to show roughly how the solution will look and how the user’s interaction will flow in the solution. There is no lengthy requirements document or specification unless there is an area of complexity that really warrants it. Otherwise the storyboards are just annotated and only where necessary.

A common approach amongst Agile Development teams is to represent each requirement, use case or user story, on a card and use a T-card system to allow stories to be moved around easily as the user/business representative on the project adjusts priorities.

Requirements are broken down into very small pieces in order to achieve this; and actually the fact it’s going on a card forces it to be broken down small. The advantage this has over lengthy documentation is that it's extremely visual and tangible; you can stand around the T-card system and whiteboard discussing progress, issues and priorities.

The timeframe of an Agile Development is fixed, whereas the features are variable. Should it be necessary to change priority or add new requirements into the project, the user/business representative physically has to remove a comparable amount of work from scope before they can place the new card into the project.

This is a big contrast to a common situation where the business owner sends numerous new and changed requirements by email and/or verbally, somehow expecting the new and existing features to still be delivered in the original timeframes. Traditional project teams that don't control changes can end up with the dreaded scope creep, one of the most common reasons for software development projects to fail.

Agile teams, by contrast, accept change; in fact they expect it. But they manage change by fixing the timescales and trading-off features.

Cards can of course be backed up by documentation as appropriate, but always the principle of agile development is to document the bare minimum amount of information that will allow a feature to be developed, and always broken down into very small units.

Using the Scrum agile management practice, requirements (or features or stories, whatever language you prefer to use) are broken down into tasks of no more than 16 hours (i.e. 2 working days) and preferably no more than 8 hours, so progress can be measured objectively on a daily basis.

One thing I think should certainly be adopted from PRINCE2, the very non-agile project management methodology, is the idea of making sure all items are deliverables rather than activities or tasks. You can see a deliverable and “kick the tyres”, in order to judge its quality and completeness. A task you cannot.

See also:
10 Key Principles of Agile Development
What are User Stories
Writing Good User Stories

read more