Requirements Definition : The Danger of Failing Before You Have Really Started

  Requirements, Stories, Use Cases, or whatever a team wants to call them form a key part of the execution plan for a development team.  It should tell them what a customer wants.  The artifacts in whatever form they are tend to have varying degrees of detail.  Getting the right amount of detail at the right time is critical to the process of producing successful software.  My thoughts on Requirements definition form around a process with three key elements.

  1. Development
  2. Prioritization
  3. Definition

  Development is first because you have to develop or brainstorm something to start with.  This generally is initially tied to a vision of what the software is supposed to do.  Over time as a product matures this phase often happens through user trials, surveys, feedback, and telemetry from the app that describes its usage and provides insight into where the app needs to evolve. This also happens as analysts evaluate the market the product fits in and based on the market’s evolution or the assumptions about where it will evolve.  In evaluating they determine what features needs to be added in order to allow the software to continue to be competitive in the marketplace.  With internal software this phase is often underappreciated and underutilized.  This is unfortunate because mistakes here whether in internal or commercial products can cause teams to miss the target market tremendously.  A mistake of one degree in a flight plan early in a flight plan causes a much greater deviation than a mistake relatively close to the target.  The Agilist in me openly admits that it is impossible to know everything upfront.  The development effort isn’t about deep detail, but broad strokes of strategy that guide the more detailed planning that occurs later.

  Prioritization comes second as the ideas developed get prioritized.  This act pares down the list of items that need to be defined in detail.  I like Scrum’s backlog analogy but I think the Product and Sprint backlogs might not be enough.  To use a baseball analogy I think you have an At-Bat Backlog, an On-Deck Backlog, and an In the Hole Backlog.  At bat would be your Sprint Backlog representing what is in play now.  On Deck represents perhaps a release backlog or something of that sorts.  These are items that are going to be in play and will need to be defined fairly soon.  In fact during a Sprint it wouldn’t be uncommon for the PM, Business Analyst, etc… to be very active in defining those items near the top of the On-Deck list.  The On-Deck list becomes a focal point in the prioritization process.  The Sprint is work committed to and while some teams might want to have a relative priority there I don’t have a firm opinion on it.  The On-Deck list is key – what will the team work on next is the question that needs to be answered by the prioritization process.  Once we have a prioritization there we can move forward with the third step in the process – Definition

  Definition in this context is providing the detail necessary to move the concept forward in the planning process and ultimately moving it successfully into the implementation phase.  Steps 2 and 3 in the process end up being a rinse and repeat type of deal.  Items will be prioritized onto a list and will need to be defined to some degree.  For example when an item is prioritized onto the On-Deck list it is likely that definition needs to happen in order for some estimates to be provided as to how long the items on the On-Deck list will take to complete (thinking of the On-Deck list as representing the functionality in a release).  As On-Deck items in the list move up – more definition is added so that the customer needs can be clearly identified and the developer can have in hand as much detail as possible when that item pops onto the At Bat Backlog.  It is here that we get to the crux of the matter that caused this post to be written.  I have seen two common behaviors that cause teams to fail relative to requirements definition.  The first is that requirements are defined too early in too much detail and not revisited effectively and as time goes on customer needs shift or change and the requirement as it was written months ago no longer accurately reflects their needs.  The second behavior is too little detail.  A story is defined with a title (which I think the whole story card/post-it thing encourages) and little else and exists like that all the way to the developer.  He has in his mind what the title means, the customer has another thing in mind, and program management has yet another.  Agile methodologies advocate the definition happen through consistent customer interaction and if that happens that can work.  All to often in practice it doesn’t work that way.

The takeaway is don’t under value the requirements process it is perhaps the most difficult thing to get right in the whole software process.  Too much detail, too soon or too little detail, too late – what is too soon and what is too late and how much is too much or little – not easy questions – the process above has worked well for me in addressing the challenges with getting requirements right.

This entry was posted in Technology. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s