Consider the following user story(ies) for a manufacturing management system I am building:
As a shipper/receiver I need to be able to create work orders So that
we can begin tracking jobs internallyAs a shipper/receiver I need to be able to update work orders So in
the case of an error at incoming I can change that before handing off
to productionAs a inspector I need to be able to change the part number/repair
scheme of a work order So in the case of a mis-identified part I can
change the work scope before actually starting
These are all tasks which would take several days to implement, once the work order UI dialog had been established and the CRUD facilities, etc were in place.
Now lets say three weeks down the road, after using the prototype, and inspector comes to me and says "Receiving created a new work order by accident; The work order already existed but the part had left the building for sub-contract work and upon it's return should have been expedited past work order creation"
I might write this story out as follows:
As a shipper/receiver I should not be able to re-create work orders
already in the system as WIP; In these cases the system should
determine the subcon and notify me of that status so I simply pass it
on through So that multiple live work orders are not duplicating each
others work scope
The story sounds quite verbose…but the requirement was literally a few lines of code added to the beginning of work order creation and took only 30 mins to add. Feels odd using a story for such a request.
Better suited for a bug tracker???
My question ultimately becomes this: When I am analyzing requirements, asking questions and figuring out high level components (ie: Work orders, repair orders, sales orders, etc) I am not focusing on specific business logic or rules but establishing components.
As a user I need to be able to create and manage work orders So that
we can begin tracking parts internally
Does it make sense to further break these down into atomic user stories, such that:
As a user I should not be able to receive a work order when…
Listing out the exceptions as individual stories?
To me this is where use-case and it's format for capturing requirements makes more sense…
Anyway what has your experience been? Opinions & comments welcome…
I am attempting to find a balance between the terse agile/scrum user story and the BUFD use-case approach to project planning (please leave the they are mutually exclusive argument for another topic)
Best Answer
Scrum doesn't really care about the type. A Feature, story, bug, thing, item, use-case... Anything can live on the product backlog. So it doesn't really matter what you call them.
The items on the top should have a decent enough level of detail so you can forecast as far as you need and so that the scrum team knows enough to start the work and be comfortable that they'll be able to finish by the end of the sprint (which doesn't necessarily mean that it's fully defined, as long as the team knows they'll be able to refine the final things during the sprint). That's the idea behind just-in-time planning and refinement. Items lower on the list may have a lot less detail as you still have time to refine them over time.
If you've chosen to use User Stories as your format, then there is generally a certain level of detail that still makes sense, then the next level is generally specified in useful test cases or acceptance criteria.
You should look at writing your acceptance criteria for your stories, the latter ones really feel more like the more detailed steps you described. Specification by Example and the "Given...When...Then..." notation would fit really well.
Only break down to a level that's needed to provide your level of forecasting and estimation. If a specific acceptance criterium would cost a lot of extra time, you may break it down into it's own story. You can always break it down at any later point in time, so only do it if you need it broken down now to set the order of implementation.
Remember that as you're refining your backlog over time, you may indeed get to a detail level that's closer to you BUFD level, but if you do, make sure that it's in some form of executable specification or in the form of test cases that you want executed, that way you don't create a lot of duplicate work.
Tools like Specflow and Cucumber can really help in doing this. Your specification is automatically mapped to Unit tests and integration tests so that you will automatically see when the work is finished by looking at your passing tests. That takes away a lot of the waste that's associated with the traditional use-case definitions. It also allows your stories to be written at a high level, then as you go into details, it's specific and easy to validate.