Once upon a time…
Over the last couple of weeks I’ve been lucky enough to get to work on a green field project. The hardest part for me has not only been trying to understand the system and domain (which I thought would be easy after getting my head around a Link Network Simulator), but also trying to extract requirements and explain how user stories work whilst I try and fit them to this particular project and working process.
Yesterday I had a revelation. The easiest way to communicate with me is to help explain systems in terms of when you put something in, then you expect something out. Explaining how it works and why it has to work like that doesn’t matter to me… yet. I need to understand how the system is expected to behave, and why, so that I can understand all the gubbins in context later on.
When documenting agile requirements, you generally start with a user story:
In order to
This answer the “Why?”. Why are we making this? Who is it for? What is the benefit? If a stakeholder can’t tell you what they want and why it would benefit the user, then it’s a sure sign they haven’t thought about it properly.
The next thing is Scenarios:
This is going back to my first statement about me understanding systems as this fuzzy magic thing that when we put a certain thing in, or a certain thing happens, then the system does some
Magic to perform certain consequence. This is your “What?”.
The problem most engineers have when trying to get these requirements down is that they’re still concentrating on the code. They prefer to work bottom up. Concentrating on the “How”, whilst making them brilliant at what they do (coding, engineering making stuff), isn’t required at this point. The behaviour of a system should not be influenced by the implementation when you’re initially trying to figure out what it’s supposed to do for the user in the story. The scenario may have to change later as implementation constrains the requirement.
So basically my revelations were “don’t explain systems to me in terms of how they work, but what they’re expected to do”, User Stories document the “Why” and “For whom?”, Scenarios answer the “What”, and your code answers the “How?”.