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.

A little introduction to my case:

As part of a bigger product, my team is asked to realize a small IDE for a DSL. The user of this product will be able to make function calls in the code and we are also asked to provide some useful function libraries. The team, together with the PO, put on the wall a certain number of user stories regarding the various libraries for the IDE user. When estimating the first of those stories, the team decided that the function call mechanism would have been an engaging but not completely obvious task, so the estimate for that user story raised up from a simple 3 to a more dangerous 5.

Coming to the problem:

The team then moved to the user stories regarding the other libraries, actually 10 stories, and added those 2 points of "function call mechanism" thing to each of those user story. This immediately raised up the total points for the product of 20 points! Everyone in the team knows that each user story could be picked up by the PO for the next iteration at any time, so we shouldn't isolate that part in one user story, but those 20 points feel so awfully unrealistic!

I've proposed a solution, but I'm absolutely not satisfied:

We created a "Design story" and put those annoying 2 points over it. However when we came to realize and demonstrate it to our customers, we were unable to show something really valuable for them about that story!

Here the problem is whether we should ignore the principle of having isolated user stories (without any dependency between them).

What would you do, or even better what have you done, in situations like this?


(a small foot-note: following a suggestion I've moved this question from stackoverflow)

share|improve this question
    
By IDE, do you mean API? Otherwise I am having trouble figuring out what you're saying. –  Steve Evers Jan 31 '11 at 10:20
    
It's an IDE (en.wikipedia.org/wiki/Integrated_development_environment) where the user can type code, compile it and debug. An important feature of the language is the ability to call functions provided by us (like "v = sin(x)"). –  Marco Ciambrone Jan 31 '11 at 11:03

3 Answers 3

up vote 4 down vote accepted

If you need to estimate several user-stories that have some elements in common, but you don't yet know in which order these stories are to be implemented, then I would split the tasks that make up each story into three groups:

  1. Common tasks, needed once: Tasks that occur for multiple stories, but which only have to be actually done only once for the first story. The mentioned function call mechanism would probably fall in this category.
  2. Common, repeated tasks: Tasks that occur in multiple stories and have to be executed anew for each story.
  3. Specific tasks: Tasks that are specific for a particular story.

Then you estimate each task, where the common tasks should be estimated only once.

In the presentation to the customer/PO, I would give two estimates for each story: One with all the "common, needed once" tasks included and one with them excluded.
Just keep a detailed accounting of the tasks, their classification and estimation at hand if the customer wants more detailed information about the difference between the estimates. The tasks themselves are not negotiable, but knowing about them could help the customer/PO, especially if the set of common tasks is not the same for each story.

share|improve this answer
1  
+1: At retrospective time, you will re-estimate all the stories because the common code has already been implemented. –  S.Lott Jan 31 '11 at 11:27
    
I think I've catched your point, however in this case we decided to avoid a deeper analysis and to favor a faster estimation of the stories, without extracting all the tasks. We actually have done something similar to your suggestion, by extracting from the stories a "common story", like a group of "common tasks, needed once". Your answer effectively go even further and will be very useful, however I still prefer a rough estimation, whenever possible, instead of a task decomposition, that I would leave to the iteration planning. - @S.Lott: this approach would leave those "annoying" 20 points.. –  Marco Ciambrone Jan 31 '11 at 14:35
    
@d3prok: The "annoying" 20 points are a temporary artifact of the approach you've chosen. They don't really exist and they go away once the common task is implemented. –  S.Lott Jan 31 '11 at 15:00

You know that you only have to do the extra work once, so putting the same extra work into 5 stories doesn't make sense. If you don't want a design story that the user can't see, then the best thing to do is to go ahead, right now, and pick one of the things dependent on that design work and say that it has to be first and add those points to that one. Make notes on the other stories that they have to come later, and if, for some reason, you change your mind, you can always move the points around.

share|improve this answer

Why software is hard.

We created a "Design story" and put those annoying 2 points over it. However when we came to realize and demonstrate it to our customers, we were unable to show something really valuable for them about that story!

Correct. The simplistic user story SCRUM is simplistic. Sometimes, the real software is complex enough that the simplistic approach doesn't work. This should not come as any kind of surprise.

Here the problem is whether we should ignore the principle of having isolated user stories (without any dependency between them).

What's your alternative? Over-price every user story because each one has a hidden one-time cost? That's equally silly.

Yes. You have to step away from simplistic.

What would you do, or even better what have you done, in situations like this?

Step away from simplistic. There are are one-time investments that make a group of stories less expensive. You have to actually talk with folks about the architecture instead of pretend that your only interaction is a list of stories to be built.

Agile means you have to actually talk with the PO and the customers.

Agile means that a simplistic process can't -- and won't -- work.

share|improve this answer
    
So, what we should have done was to show to our PO+customers that on the way to the completion of each of those 20 user stories (real value/money for them) there was a technical step to overcome. This would have helped in letting them realize the importance of such a "design story" and consequently put them in a better position to prioritize that work. Did I understood well? –  Marco Ciambrone Jan 31 '11 at 11:53
    
@d3prok: "letting them realize the importance of such a "design story" and consequently put them in a better position to prioritize that work" Yes. Agile methods like Scrum require you to talk with PO and customer. Conversations. Discussions. Interactions. An unthinking formal process of 'story-estimate-prioritize-build' is the exact thing you're supposed to avoid doing. –  S.Lott Jan 31 '11 at 12:47
    
this was a very useful answer, I would like to give you a point but unfortunately my reputation is too low here on programmers... Thank you S.Lott! –  Marco Ciambrone Feb 1 '11 at 14:08

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.