This is the second post on a new definition of ‘epic’. The first post is all about types of story. If you haven’t read that first post, it might be a good idea to read that first. This post looks at the other elements (not stories per se) that crop up as inputs to requirements.
On day one, before running any workshops or conducting any interviews, you have to become familiar with the documents that have already been written. There might be reports, or project mandates, or business cases to read, or whatever. A good approach is to read the documents and start creating index cards for each salient point you encounter. Then it’s a question of making sense of them, categorising them, and creating a requirements hierarchy. Let me be absolutely clear on the point that I am not advocating a big requirements effort upfront reminiscent of ‘waterfall’. I’m just taking the pragmatic approach that whatever you do going forward, there is a need to make sense of what’s already gone on. This can be termed ‘traceability’. How can you demonstrate that what you propose in a couple of weeks time (a nicely groomed backlog – filled with implementable testable functional stories) satisfies all the inputs that have already been given?
Non-story inputs include:
- Constraints: a condition that must not be broken
- Non-functional requirement: a condition that must be exhibited
- Business rules: related to a particular story (functional behaviour). Implemented as an if…then… condition. Often related to ‘state’ of a business object
- Implementation tales: someone’s suggestion as to how the solution will be implemented
- Acceptance criteria: related to a particular story (functional behaviour). A test that can be run to determine whether a story concludes in the manner desired
Even if you are starting the project from the outset, not everything people tell you is going to make a good candidate story. Take ‘security’. Say somebody tells you the system needs to be ‘secure’. This seems like a statement of the obvious; of course the system needs to be secure. Are you going to write a story:
As a data specialist
I need to ensure our customer data is secure from outside hacking and mis-use
So that data is not stolen and customers compromised bringing bad publicity on to the organisation
Clearly it is possible to describe ‘security’ as a story (as demonstrated above) but is it the best way of articulating the need? Is it the best use of your time? There are no hard and fast rules about categorisation, but there are guidelines (although there remains ambiguity and we can argue about it). Again though, remember we are ultimately aiming to get that well-groomed backlog created, and that means defining stories the programmers can implement as functional behaviour. Nobody is going to use your new system and come to it with the express objective of ensuring their data is secure. They are just going to use it with the expectation their data is secure. The system needs to function without breaking the rule that data is secure, so it’s natural to see ‘security’ as a constraint; behaviour that is not violated while the system is in use.
Figure: A new definition of a ‘project epic’.
