Feature Injection A Gentle Introduction by Kent McDonald with sporadic contributions by Chris Matts
Most of today’s sessions are about business analysis. This Feature Injection approach looks a lot like what I do, but explained at a very high level. Essentially it boils down to:
- Identify Value: make sure you have a business value model which defines the type of value projects seek: increase revenue, decrease cost, protect revenue, reduce risk, increase information…
- Identify Capabilities: what is the minimum set of capabilities we need to realise the value(s)?
- Get lots of examples: understand what exactly happens in different circumstances
Or stated differently:
TO realise < identified value> AS A <actor> I NEED <identified capbility>. GIVEN <example situation>, WHEN <example action> THEN <example outcome>.
Now we just need a way to find those pesky actors who deliver the value.
Beyond User Stories: Identifying Missing Links in Your Product Backlog by Ellen Gottesdiener
This session focused on the requirements that don’t neatly fit into the User Story mold: non-functional qualities, implementation and design constraints, cross-cutting concerns. How do we represent these?
- Write specific User Stories. E.g. AS A CTO I NEED the solution to be deployed into environment X SO THAT our support costs remain constant. The advantage is that the rationale is clear. The disadvantage: this story is never done.
- Add extra constraints to the User Story. E.g. AS AN accountant I NEED report X in 5 seconds SO THAT….. The advantage is that the information is directly associated with the story and has user meaning. The disadvantage is that there are usually several criteria, so the User Story might get very complicated.
- Add constraints to the “iteration definition of done” or “release definition of done”. E.g. all modified or new functionalities must be documented in the User Manual before the iteration ends. Advantage: useful for recurring needs. Disadvantage: may lead to implementing and testing these requirements late, so that nothing is really DONE until the end of the iteration or release, batching up work at the end.
- Add acceptance criteria. E.g. GIVEN a session at the conference WHEN I select the details THEN the full session description is displayed within 3 seconds on any web browsing device. Advantage: concrete, leads to lots of questions as we explore scenarios, leads to automated acceptance tests. Disadvantage: where do you put the tests: story, module, application, global?
- Other techniques like planguage or simplified text descriptions of constraints.
One extra tip I would add: define service levels.
Service levels
For many non-functional criteria we can define a limited set of “service levels”. For example we could have three security levels:
- Top secret: nobody can see it, until it’s published in the newspaper
- Private: only the person concerned + HR can access the information
- Public: anybody can access the information
Or we could do the same for response levels:
- Blistering: answers within one second
- Snappy: answers within 3 seconds 98% of the time
- Relaxing: answers within the time to take a lunch break
Now, instead of discussing (haggling) over details of non-functional requirements (“is 1.5 seconds fast enough? No? 1.4 seconds?…”) we put each story into a service level “bin”. Most User Stories can be classified quickly. We can annotate the User Story with the appropriate set of Service levels in each of the dimensions. We can subject the User Story to standardised acceptance tests that verify if the implementation does indeed comply with the rules of the service level.
For those few stories where the standard service levels aren’t a good fit, we can create customised criteria and tests. And of course, we’ll review and update the service levels when we see that the classification doesn’t fit any more. As long as we keep it simple, with few levels, we can communicate and work efficiently.
More games
This afternoon I go to see two more games:
