Agile Stories and Tasks

Question

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?

Answer 1

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)

Answer 2

I base the stories on the public interface of the classes. For task granularity I shoot for work effort of half a day to two days.

Answer 3

A user/ actor can be a system, not necessarily a person. Your services will have an API, expected input and results and a service level agreements (non-functional requirements). All of those can be specified in the story card.

Most importantly, your story card should specify acceptance criteria. Accpetance criteria will help drive the developers Test Deiven Development Unit Tests, the automated functional tests and the automated performance tests. If the acceptance criteria is meet, the card is accepted and approved by the product owner.

Answer 4

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:

• Document
• Write Test Cases
• Manual Test
• Write automated functional tests etc.

Hope this helps, Assaf.