Menu
When designing a back-end system, what granularity do you normally give your stories and tasks?
Most examples of creating stories and tasks usually center around a GUI application with the story being something the user can do (e.g. search for a book by the ISBN) and each task centered around enabling this GUI feature.
When designing a back-end system, i.e. one that doesn't have a user interface but is just a bunch of services talking to databases, middleware, etc. how do you come up with tasks and stories?
520
There are a few important things to consider when breaking down user stories into tasks: Keep tasks small, but not too small. As a rule of thumb, a task should be something that can be done within a single day, but not in a few minutes' time either. Keep tasks very precise in scope.
The unfinished User Stories should go back to the product backlog, be re-estimated, and considered for the next Sprint. Re-estimating the user stories ensures that the future work is true to the point estimate. The work performed during the current sprint is “lost” as far as the worked points.
Q #17) What happens when all the Sprint Items cannot be completed? In a case where the team is unable to complete all the Sprint Backlog items, nothing happens. The Sprint ends on the stipulated date with the completed items.
Basically, I try to keep the size of my User Stories in the area of 1 to 10 man-days to complete. That keeps me from passing what Mike Cohn calls "Epics" or "Themes" as user stories to the developers, and on the other size stopping my user-stories to be so specific as to imply the solution (they should be describing the problem, not how it should be solved).
As far as content goes, I make sure that my stories contain only business value - it never describes how I (should) satisfy the demand, nor does it "require" non-user-domain knowledge to understand.
Good example: As a content manager, I want all users to have to log in before writing a talk-back, in order to deny them the ability to spam.
Bad example: Add captcha to the web site.
Tasks, on the other hand, are steps towards solving the solution - they describe components & functionality that need to be added / modified. This is where an "Add Captcha" solution comes in. As far as size goes, I try to have each task's size be between 1/2 a day and 2-3 days of work.
Tasks also include a set of standard tasks that apply to each and every feature / requirement / problem / bug, such as:
Hope this helps, Assaf.
95
As long as you have users, user stories can be around things users can do. If you are providing an API for other developers, then they are your users. Things will get more technical at that point (i.e. User can update Employee records)
21
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
