People doing Scrum-like methods often decline the story point terminology due to “our requirements are not transformable into user stories because of…”-reasons.
My typical response is to ask them “ok, but as long as you set the context, define ready and acceptance criteria – then it’s all fine”.
From my point of view there are three important aspects of user stories:
- They describe the context of the requirements
- They scope the task by having measureable done criteria
- They prescribe what needs to be completed before starting implementation
If you can handle these elements on your regular requirements, then I’m in full approval.
So, how do you actually transform requirements?
Look at this example:
“Change the call on line 55 of calculator.cpp from ‘return int(round(val));’ to ‘return val;’ and also change the function to return float values.”
This might not be the prototypical requirements that you see – but I’ve seen variations of this happening very often.
The requirement states two obvious tasks:
- Change line 55
- Change the function definition
What it doesn’t state is:
- What is the expected outcome of this test?
- Who should verify it?
Asking these questions might reveal:
- The sales department has sold a version of our calculator which is able to handle non-integer numbers with decimals
- When implemented it’s expected that a user could perform decimal number calculations
Summing all this up might give the following:
“As a user I’d like to be able to calculate using decimal numbers”
Ready criteria: User interface design should be designed and agreed
Done criteria: 10,3+2,23=12,53 and 10,3-2,23=8,07
Now, wasn’t that simple? 🙂