Practical solutions for requirements gathering: making it count

About this post

The first post in this series showed how to lay the groundwork for a successful project, with the follow-up post covering some of the different methods that can be used to reach a shared understanding of project requirements. In the final post in this series we’ll look at how this understanding can be converted into nine valuable assets that will allow your development team to start writing code.

Asset 1 – product vision

The product vision is often said to give the project its ‘true north’ – acting as a constant guide to the direction in which the project is (supposed to be) heading. Essentially, it is a succinct statement of who the product is for, why they need it, what ‘it’ actually is, and what value users will derive once it has been delivered.

It is important to recognise that a product vision is not the same as a business or product strategy. The product vision is a high-level definition of what the product is seeking to solve or achieve; the product strategy is a high-level approach to how you deliver that vision. If you have done your homework (as discussed in the previous posts), you should be able to define a well-informed and clear product vision. This should not change significantly over the course of the project, although you may change or refine your strategy as the project progresses.

A useful tool when defining your product vision, and one that is used at Box UK, is Roman Pilcher’s Product Vision Board.

Asset 2 – user profiles

Having completed your product vision, it’s important to next look at your users in more detail. Creating user profiles will better inform your efforts later in the project when you’re working to identify the value and priorities of feature development; as we will see below, these artefacts are the starting point for user stories, and so it is important to be confident that you know how those users are likely to behave when using your product.

User characteristics to consider in relation to the product include: frequency of use; expertise in domain (i.e. the familiarity of users with the content your product will serve up); general IT proficiency; proficiency with the current (or similar) system; and the user’s general goal (this may be increased convenience, speed or support, for example).

Once sufficient profiles have been defined, it may be possible to group different users into distinct roles such as Administrator, Consumer, Editor, etc. It’s also useful to think about those users you actively don’t want on your system, such as criminals, or competitors who wish to take information and use it to achieve commercial advantage. To that end, you can also research and define “Abuser Profiles”; capturing information on the goals of undesirable users can inform how you might build your system to prevent them reaching these goals. Users may have different roles depending on their intent so be careful not to oversimplify or miss subtle but important differences in your profiles and personas.

Asset 3 – user stories

In the first post in this series, Andrew explained how detailed requirements documents sometimes fail to deliver successful products. An effective alternative to these unwieldy documents is user stories – a simple but powerful way of capturing user requirements. Using the model “As a [type of user], I want [to do something], so that I can [get some benefits]”, this approach enables product requirements to be defined in small, manageable units.

Example user story

User stories should not just be seen as a different way of writing a requirement; they are much more powerful than that. For example, user stories start with a commitment to looking at a problem from the point of view of a variety of end users, validating that one or more of those end users really do have that problem, and that a solution to that problem would be valuable.

However, the real goal of user stories is to help generate and maintain a genuinely shared understanding across the project team (including the customer!), of the problem and potential solutions. This is important as many defects or project pain-points occur due to misinterpretations of some element of a requirement or a solution, when a shared understanding has not been reached and so some part of the solution does not meet the expectations of a client or team. The key to achieving shared understanding is to have empowered, cross-functional conversations about the problem and potential solutions; user stories are a useful tool to facilitate and provide reminders of those conversations.

Depending on the preferences of the project team, you may start small and work your way up to the big features you want to see in the product or you may start big and gradually break those overarching ideas into smaller and smaller chunks; alternatively you may find that you start with a bit of both. In any event, at some point you will need everything broken down into chunks of work that are the right size for development.

A good yardstick for judging if a user story has been defined to the right level of detail is INVEST:

• Independent: a story should not have any dependencies. Some dependencies may be unavoidable but too many and your product will become locked into a rigid development delivery.
• Negotiable: in keeping with the principles of Agile, the story should not be fixed or immune to advances in your understanding of the the product. Don’t forget, user stories are a part of the conversation toward a shared understanding.
• Valuable: if the story does not bring value to the end user, don’t do it!
• Estimable: while estimation is hard, some idea of the effort required to deliver the story is crucial, particularly where you have a hard deadline and need to negotiate on features.
• Sized Appropriately: small really is beautiful in Agile. But not too small! Going into too much granular detail will stifle the conversation about requirements and frustrate participants. Appropriately small stories will give you flexibility in planning and release management.
• Testable: all stories must be testable – how else will you know that the story delivers what is intended? (See also acceptance criteria below.)

If you are new to user stories, you will probably find that, initially, creating INVEST stories is a challenge. As your skill and comfort with user stories develops, however, INVEST will become second nature and you will very quickly apply it automatically – like properly-prepared ingredients for a satisfying meal!

Asset 4 – user story maps

As mentioned above, when building your backlog of user stories, you may have a combination of large and small stories. The large stories will have to be broken down into smaller stories at some point, but avoid the trap of going into detail for all stories. It’s also important be mindful of priorities; a user story map is a useful way of organising your stories into a narrative from which you can see those aspects of your project that take priority over others.

User story map. Credit: www.jpattonassociates.com

Not everything can, or should, be developed at once and your objective should be to develop a product that brings immediate value to the user as quickly as possible. Remember that Agile is all about feedback: development should be based on evidence of what works – not just intuition.

A user story map is also a useful way to understand, and keep an eye on, the scope of your product. Scope creep is a familiar challenge in all projects but having a user story map will keep you honest about the value being delivered and from that, your prioritisation of requirements.

Asset 5 – Acceptance Criteria (A/C)

Really an extension of the conversation about a requirement, well-drafted acceptance criteria allow the development team to know when they have met the requirement. Avoiding subjective, vague terms like “reasonable”, “good” or “enough”, A/C specify the minimum acceptable behaviour or results of a user story and should include a clear expression of intent, clear pass/fail criteria (no partial acceptance), and any functional and non-functional aspects. A/C may also suggest a solution but tread carefully here – solutionising in advance of development may undermine shared understanding.

Example A/C (for user story above)

Again, acceptance criteria should not be written in isolation and ‘thrown over the fence’ – deriving the right acceptance criteria should be a collaborative effort between customer and developer organisations. As A/C also form the basis for sign-off on development, they are a critical element of knowing when you are ‘done’ developing a user story, but can (and should!) evolve with your conversations up to the point where a shared understanding has been achieved and the story is ready to begin development work on.

Asset 6 – “Definition of Done”

With Agile, the end of each development period (sprint) must produce working, valuable software to an agreed production level of quality. If any features have been developed but not yet completed, there is a risk that this will introduce instability and confusion into the product code. Over time this could become fatal as developers move away from the shared understanding and begin to fill in gaps in understanding with their own assumptions.

The “Definition of Done” is your project sense-check, allowing you to define the point at which development can be said to have been completed. While each project can have its own definition of done, the following is a good example of a considered and effective definition:

Outputs:

• Pass acceptance criteria
• Meet any user experience and design specifications

Code is:

• Well-written (according to any coding standards adopted by your development team)
• Checked-in, accompanied by system/unit tests
• Code-reviewed
• Appropriately documented

Quality:

• Very often perfection is the enemy of ‘good’ so it is important to understand when development is ‘done well’.

Bear in mind that it is easy to confuse ‘high quality’ with ‘lots of features’, and that a feature must always deliver value to the user. Developing lots of features may feel like you are delivering lots of value, but you may be missing what is truly valuable to the user, as well as missing opportunities for feedback and evidenced-based prioritisation. Speaking of which…

Asset 7 – prioritised list

Prioritisation is needed to make sure that the development team does the right work at the right time. This could be to deliver the highest-value features early in the project, it could be to deliver features with the biggest cost/benefit balance first, or it could be to de-risk a particularly risky but high-value feature. It bears repeating what has been said before about prioritisation:

“As everything becomes important, everything becomes equally unimportant”

David B. Clarke, “Consumer Society and the Post-Modern City”

Without some means of measuring importance prioritisation is impossible; subsequently you will not be able to provide effective guidance for your stakeholders, either as to what should be developed first (for your developers), or what can be expected in upcoming deliveries (for customers).

There are many methods to support effective prioritisation, but the two most often used at Box UK are MoSCoW and the priority matrix. With MoSCoW you categorise your user stories on a descending scale of Must Haves, Should Haves, Could Haves and Would Haves. By being honest about what is genuinely critical, it should be possible to work from there and effectively prioritise your list of user stories.

The priority matrix is different from MoSCoW but the objective is the same: analyse your user stories in such a way that you are able to understand the relative importance of each story. The matrix, however, is a more visual tool than MoSCoW and you may find that this helps concentrate minds and spark conversations that bring out a more considered appreciation of importance.

(Remember, too, that if your aim is to develop a Minimum Viable Product, the development schedule should only include those stories that are considered critical.)

Asset 8 – product backlog

At its simplest, a product backlog is a list of user stories derived from a user story map. A backlog can also hold bugs that need to be addressed, technical work (such as development environments and hosting) that needs to be completed, and questions that need to be answered (usually things that were not known or anticipated at the outset). A good product owner will always have a comprehensive understanding of the backlog – including relative priorities.

Once sufficient user stories have been drawn from the backlog and estimated, a sprint plan can be agreed between the product team and the development team. Whatever estimation method you use, the objective is to ensure that the maximum feasible amount of work can be done by the development team in the time allowed (usually two weeks) – no more and no less. Estimation is something of an art form but you will find that as your project progresses, knowledge of the technical aspects of the product become clearer and the team starts to work more seamlessly together, increasing the ability to estimate accurately.

Be careful not to estimate every detail in the backlog though – not everything should be estimable as the further down the backlog you go, user stories should become less detailed (to permit changes as feedback comes in on previous iterations). Also, any estimates done too far in advance of development will in all likelihood change as your development team becomes more familiar with the particular demands of the product. Estimation is already hard enough without having to do it many times over!

While a backlog could take the form of a simple spreadsheet or even a list of post-its on a board, it is more common for product teams to use a project management system, such as the one used by Box UK: JIRA. Project management systems allow the backlog to be easily maintained and, crucially, make it visible to the whole team – locally and remotely. Such systems also typically offer a wealth of built-in reporting, allowing you to monitor progress against any KPIs binding the project.

Asset 9 – C4 diagram

While not a development task, you may find it useful to use some form of diagram to represent the ‘big picture’ (as part of maintaining that all-important shared understanding). A tried-and-tested approach is the C4 method, so-called because it uses the 4 ‘Cs’ of Context, Containers, Components and Classes.

In reality C4 is simply a defined method for breaking down system complexity from a high level (overall context) to a low level (technical solutions) using a series of relatively simple diagrams.

At the highest level, context, the focus should be on users and the position of your product within the user environment. The general classes of user should be identified in your context diagram. Also, your product may depend on integrations with external systems such as Twitter or Facebook, or internal services such as a Customer Relationship Management (CRM) solution. A context-level diagram will help everyone understand environmental dependencies and not lose sight of what space the product is intended to fill.

4C diagram at Context level. Credit: www.dzone.com

The next level down, containers, allows some of the technology choices to be highlighted. A ‘container’ in this context is anything that stores or processes data, including databases, file stores, desktop applications, mobile applications, etc. The container diagram will show where each of these systems communicate with each other – useful not just for your developers, but also for your infrastructure team maintaining all the development (and possibly deployment) environments. At this level, many non-technical stakeholders will still be able to follow the diagram, so it can be a useful tool to highlight technical project aspects to a non-technical audience.

Further levels of detail can be added but you may find that the audience for these diagrams becomes more specialised as the detail becomes more technical in nature. Only go into further detail if there is value in doing so; if no one is likely to read down to the level of components and classes, don’t do it! A fuller explanation of the C4 method can be found here and again, these diagrams are best when they are derived collaboratively, acting as further invitations to conversation.

Conclusion

Agile is a team effort, focused not on lengthy and static documentation but on conversations that build the shared understanding needed to achieve required business outcomes. And it’s these conversations that bear the succinct and valuable assets that will put you in a position of readiness for development – as well as ensure your developers (and all other necessary stakeholders) understand your story, to ultimately support the delivery of a useful and successful product.