Last year, I was part of a team that invested heavily in making its application development pipeline ‘agile’ by adopting the Agile/Scrum methodology.  We did this for a number of reasons, but one thing I noted while we were on that journey was the need for a pipeline of good, robust requirements. As our agile process matured, our requirements became hyper focussed on what the user benefits were and their measures of success. Where previously we had focussed on the components and technologies we had to build, the focus had switched to the incremental benefits we could bring to our users. The real success was that by incrementally developing features in line with the amount of user benefit that would be received, we could deliver those features to our users faster. Those new features were the ones our users wanted the most and when they started to battle test those features in the real world, our users had a raft of new, more important requirements we'd never even discussed before! Feedback that we might have had to wait months for before. Suddenly we were building the products our users needed rather than the ones they thought they wanted from the outset.

We had gone from being solution based, to being user based. I spent less time prioritizing the components, technologies and integrations and more time discussing the user benefit of each incremental feature. Once the user benefits were clearly articulated, it suddenly became much easier for the team to prioritize the pipeline of work and, as the development team became more mature, the clean requirements allowed them to think creatively on how to develop solutions (it’s amazing how many different ways people can solve the same problem). Having concise, clear requirements helped the team to prioritize the right problems to solve and let the development team figure out how to best solve them. It also helped us to break large problems down into the elements that will deliver the most user value first. For example, if I implement a search feature across a particular dataset, the most basic story might be for that search to return results for an exact match, while fuzzy matching or stemming might come later. 

In the agile methodology, requirements are called stories and the definition of the requirements are called acceptance criteria. The story is easy to understand and clearly articulates the benefit to the user. The acceptance criteria are written like a set of observable test cases so that it's explicitly clear what the expected result would be for the user given a precondition and action. With the story and acceptance criteria documented, everyone on the development team should be able to understand what the benefit to the user is, and how to tell when the requirement has been met.

The generic version of a story and one of it's acceptance criteria could be:

• Story - As a <role>, I want <ability>, so that <context>
  • Acceptance Criteria - Given that <precondition>, when I <action>, then <result>

There’s no reason why, working on a data project, it’s not feasible to come up with the same set of requirements and treat the development of data products in the same way as you would for any other application. Taking that search feature as an example, let's build a story and some acceptance criteria:

• As an analyst, I need to identify exceptions that match a search term, so that I can easily report on exceptions related to a particular topic.

  • Given that an exception exists matching my search term, when I search for that term exactly as it appears, I expect to see the result returned (Exact match)

  • Given that an exception exists matching my search term, when I search for that term, I expect to see the following data points in the result (ID, Summary, Description, Date Raised)

  • Given that an exception does not exist matching my search term, when I search for that term, I expect to see a message saying ‘no results were found’

Getting a team to start documenting requirements this way can be a challenge and requires discipline, training and patience, but once the practice is in place it can provide a world of transparency into how projects are progressing, what requirements have been implemented and what's yet to be tackled. Breaking requirements down into discrete stories and implementing incremental value like this also allows development teams to get real production feedback from their users and respond to changing requirements in a way that would be difficult to achieve otherwise.

Let me know if you're using agile techniques to build your data products, what's worked and what has proved challenging.

Leave a comment below or send me a message @eageranalyst