8 tips on managing requirements

requirements-boxI have been looking recently at managing requirements for new projects. I thought it would be interesting to share our top lean-agile tips/encouragements for for managers of requirements (i.e. the product owner role in agile terminology):

Tip #1: Do only enough requirements work up front to enable you to build the first (small) feature. Then learn and adjust!

How much do we need to work out up front and how much can evolve as we build the solution? Defining all the requirements work up front (Big Requirements Up Front) seems attractive. It means that there can be a contractual style relationship between business folk and solution builders. Commitments can be made and, if an external vendor is involved, fixed price deals can be made. If dates, budgets etc. are not met then punishment can be handed out etc.

Yet this is not the way the IT industry is going. The biggest risk in IT development is that the solution delivers little or no value (unused features). The whole agile movement has this in focus. The IT industry has learnt that Big Requirements Up Front actually increase this risk because the delay the point when we are going to get feedback on our requirements. There are always large uncertainties in what the customer needs and how to build it. Its never been done before! A lean-agile approach emphasises learning – build a bit and get a response so we don’t have to get it right first time.

Wait, I hear you say. Doesn’t this mean that you might not take all business requirements into account from the start and have to refactor/reimplement certain features later? Yep, it probably does mean this. IT industry experience suggests that these refactoring costs are typically much smaller than the costs required to get it right first time. (See here for more details).

Tip #2: See requirements as a placeholder for a conversation, not the conversation itself.

Consider requirements as a placeholder for a conversation between the people who have a business need and the developer writing the code. They are not the conversation itself.

To align everybody around the direction we want to head in, a short up-to-date document describing the project vision (better a short document which everybody has read than a longer one that hasn’t been read at all). Beyond this, user stories are usually the best format to capture requirements since they capture the intention of the requirement (“in order to”) and who wants this requirement (“as a”). Otherwise, these things are often lost. e.g.

AS A: Flickr member
I WANT TO: be able to assign different privacy levels to my photos
IN ORDER TO: control who I share which photos with

Tip #3: Break requirements down

User stories can be arranged into hierarchies with top level stories which are broken down into smaller stories. Keep breaking the work down until you get to a feature that can’t be broken any further and still retain some business value (a minimal marketable feature in the jargon).

Tip #4: Define acceptance criteria up front

How will we know when a requirement has been delivered? Ensure user stories have acceptance criteria so we know when we are done.

AS A: Flickr member
I WANT TO: be able to assign different privacy levels to my photos
IN ORDER TO: control who I share which photos with
ACCEPTANCE CRITERIA
-

A user cannot submit a form without completing all the mandatory fields
– Information from the form is stored in the registrations database
– Protection against spam is working
– Payment can be made via credit card
– An acknowledgment email is sent to the user after submitting the form.


Tip #5: Collaborate like crazy, preferably face-2-face

Two of the the principles behind the agile manifesto are: “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” and “Business people and developers must work together daily throughout the project” Geographic constraints may hinder this but try and get as close to this ideal as you can. Be available throughout development/testing/ etc. for questions (e.g. attend the daily stand-up). If you don’t do this, the fast feedback model won’t work.

Tip #6: Use CD3 for prioritising and be prepared to stop early

Use the economic model cost-of-delay divided by duration as the basis for prioritising requirements. This also means that we have the option to stop early when we have delivered the most valuable requirements.

Tip #7: Smooth the end2end requirements flow

Requirements need to flow into a development team. There is no point developing requirements too early (requirements go stale very quickly). Equally, there is no point having a development team standing idle. Ensure the people who are actually going to build the solution (i.e. coders, not managers) participate the the refining of the user stories. It these people are not available now, wait until they are. It’s counterproductive to create a large queue of requirements that are waiting to be implemented.

 

Tip #8: Explain to business stakeholders how they need to behave

It’s helpful to explain to business stakeholders what kind of behaviour from them would support a successful outcome:

  • Charter the team to deliver the best possible value in a fixed time scale. Be cautious about asking for a fixed scope by a fixed date. The team will probably have to do Big-Requirements-Up-Front (BRUF) in order to have enough information to commit which significantly raises the risk of failure. It may also mean that invisible factors, like quality, are compromised.
  • Provide $ cost-of-delay/week and trust the team to make the right trade offs. Saying that “this is top priority” or “the board wants this” etc., gives the team no guidance about how to trade off against other high priority items.
  • Trust the team.
  • Make sure business people are available to quickly give feedback.
  • Insist on getting to see something of business value working in production quickly (30-90 days from project start) .
  • Insist on a weekly demonstration of progress.
  • Insist on regularly attending the team stand-up.
  • Insist that the team commit to dates on near-term work items (typically for the next 2-4 weeks).
  • Insist on an up-to-date roadmap covering a longer period. Don’t expect a lot of detail on this.
  • Stop/abandon the project early if you feel you’ve got enough value.

Leave a Reply