Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When just starting a project, you have nothing---no UI, no data layer, nothing in between. Thus, a single story like "users should be able to view their foos" will entail a lot of work. Once you have that story, one like "users should be able to edit their foos" is more realistic, but that first story will involve setting up a UI layer, a presentation logic layer, a domain logic layer, and a data access layer.

This doesn't fit with my concept of "tasks": to me, I'd rather have something like the following "tasks":

  • Show dummy data for a user's foos in HTML, derived from JavaScript objects.
  • Set up a presentation logic layer, and connect the JavaScript objects to it.
  • Set up a domain logic layer, and connect the presentation logic layer to it.
  • Set up a data access layer, and connection the domain logic layer to it.

Do all of these fall under the single "story" above? If so, I feel like stories are not a terribly useful framework in the early stages of a project. If so, that's fine---I just want to make sure I'm not missing something, since I'm really trying to learn this agile methodology as best I can.

share|improve this question

3 Answers 3

up vote 5 down vote accepted

This is a good question and there are probably several good answers to it. My take is this:

A story is a user story so it must be defined in terms that describe how it benefits the user.

If Agile and stories are going to work for you, then they should work even in the beginning stages. The first bullet point is a single user story (worded a bit tech-y though), but the other three are technical task descriptions.

In the beginning stages of a project, when you don't have the appropriate frameworks in place to make CRUD (Create, Read, Update, Delete) development quick and easy, your stories need to be of much smaller, incremental pieces.

Instead of "User should be able to view their foo", something like this:

  1. User should be able to see a page with sample data
  2. User should be able to see a page with interactive sample data
  3. User should be able to see a page with live interactive sample data

Remember that most user stories that seem too huge to develop in a single sprint (I've found that anything bigger than about 8 story points, or days of development, was too big) can probably be broken down into pieces that are still meaningful to the user.

The story/feature doesn't have to be marketable, it just has to be meaningful to the product owner. In the case above, you could put in some quick demo pieces to show what has changed and how that story is now done — for example, for #3, you could show the page for two different users with data pre-populated in the database. At stage #2, all users would see the same data.

share|improve this answer
    
This was the most helpful answer to me, because it gave examples of more granular user stories. I think I miscommunicated my question; I know that my "tasks" are not user stories, but I was hoping their was something with similar granularity that would still qualify. The stories you gave were exactly what I was looking for. –  Domenic Jan 15 '11 at 0:54
    
Confused about the "It doesn't have to be releasable" bit. Could you explain further? As I recall, all user stories requirements have to be completed in order for the story to be considered completed. Holding off on downvote to see if explanation helps. –  indyK1ng Jan 15 '11 at 1:40
    
@indyK1ng I didn't think about the double meaning. I meant that not every story has to be a marketable feature. Of course, to be considered complete any code should be of release-ready quality. (Edited answer) –  NickC Jan 15 '11 at 2:39

I think what your are missing is that user stories are about describing how the user expects to use the system. This is a way of determining the business requirements. They are not designed to directly tell you what to do technically, which is what you seem to be wanting.

This is arguably one of the most important parts of a project. If you do not get the business requirements correct then the system will be of no use to the users.

share|improve this answer
1  
+1 - what I wrote only more succinct. –  quickly_now Jan 15 '11 at 0:51

What you are asking is essential "how do you think about the problem space" in order to break it up into sensible pieces, from which you can do a design.

Whether you call this the user story, or analysis, or decompostion, or specification, or requirements gathering... in the end it comes down to several things which normally will have some iteration.

You need to get from the users heads what they want. (They probably know some of what they want, and want things that are inconsistent but can't yet see that.)

You need to capture this in some form - you really only have 2 choices: words or pictures. Both have power, use them both if you can. Words are ultimately more powerful from the point of view of a contractual dispute later.

You need to present this back and seek agreement.

Some people do early visual prototypes with no business or other logic behind. This can be a powerful technique - up to a point because it still involves a certain amount of hand-waving.

Some will story-board - and then present and explain.

Some will write rigorous and carefully analysed documents.

Each technique has its advantages and disadvantages.

About the only counsel I'd give is: Leaping in to coding a solution too early is usually a bad move. Understanding WHAT to do, for WHO, and WHY, before you do it generally leads to less rework, and a faster development.

When you talk about "tasks" this seems to me like some kind of break down of the work, having figured out the above what, who and why. You can't figure out tasks WELL until you have the user story understood, in a document, approved by the customer as the scope of the work you are going to do. Knowing what you are have to achieve (the output) allows you to figure out the tasks (the steps involved in getting there).

Don't skimp on the front end analysis and documentation.

share|improve this answer
    
+1 for advocating more upfront thinking –  Gary Rowe Jan 15 '11 at 9:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.