1

I have read that story point estimation is not intended to actually tie with number of hours , but is used to identify the relative capacity. I have a java application which has a adapter layer , a service implementation layer , a DAO layer and an external connector service layer. If I am given a high level requirement , is it a good practice to a classification of story points for each layer - eg:

Adapter : small : 1 SP , medium 3 SP , Large : 5 SP , Extra Large : 8 SP Impl : small : 3 SP , medium 5 SP , Large : 8 SP , Extra Large : 11 SP DAO : small : 1 SP , medium 3 SP , Large : 5 SP , Extra Large : 8 SP

Is it a good way of estimation? Or should we always estimate by looking as application as whole for each change? For eg, If I have got 2 user stories , should I estimate size of user story as a whole , say 1 US takes up 5 SP and other takes 13 SP? Does component-wise breakdown make sense for story point estimation?

Improve this question

1 Answer 1

Reset to default
1

In agile methods, there are usually two levels at which estimations are done: The level of a whole User Story and the level of the Tasks that are needed to realize a User Story.

If you are estimating on the User Story level, you should estimate the User Story as a whole, for two reasons:

  1. If you break the story into layers/components, then that implies that somebody (presumably the product owner) has already made design decisions on how the story should be implemented. But that should not be part of a User Story. A User Story gives who needs what and why they need it, but the how is reserved to the development team that has to realize it. This is a very important difference with traditional requirement formulations that often tend to step into the how-realm.

  2. In your proposal, a medium "story part" in the adapter layer is 3 SP, but in the service layer it is 5 SP. This difference in sizing between the layers will cause confusion eventually. The team will have to keep three or four references in their mind for how much effort corresponds with say 3 SP to account for the different scales used in the different layers.

Using different scales within one estimation should be avoided as much as possible (I would even say, at all costs), so even when the team is estimating the individual tasks of the story. The units used for task estimation don't have to match those for story estimation (you can even use hours for task estimation, because a typical task should be between 2 and 8 hours anyway), but within one estimation you should use the same units.

Suppose that storypoint estimations were used for the individual tasks, with the units per layer as you indicated in your question and a task comes up that could be implemented in either the adapter or the service layers. Just knowing that it is a medium complexity task or that it is a 5 SP task does not tell you anything, because you still have to know what layer was envisioned to implement it in when giving the estimate.

Improve this answer
1
  • Thanks Bart. In my case the application is already existing and whenever a new enhancement comes through one or more components that I had listed might be impacted. In our case the estimation needs to be done by the development team and would not be done by the product owner. But I gather that based on your answer component level estimation should not be done in case of an agile project.
    – Punter Vicky
    Oct 12, 2013 at 13:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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