Story estimation problem
Hi everybody,
The situation :
In our backlog we have 7 stories concerning web services. Each story is about creating one webservice.
I think having one webservice per story is a good idea because each one have business value without the others and they have different values for the product owner so that he can prioritize them.
The problem :
The team estimated each story to 5 points but thinks the first will be more difficult. If we keep these estimations the team will probably do two stories during the next sprint (10 points) and the five others in the second (25 points) and the velocity of 25 will be wrong. If we estimate that the first will be 5 points and others 2 for example we will be forced to do the 5 points story first. The third solution is to change the estimations of all stories except one but only during the sprint planning so that the product owner can still reorder the stories.
What do you think ?
Thanks for your time and your help.
Hi Anthony,
When we say a story-point, it is regarded as the COST rather than the VALUE.
Velocity measures OUTPUT, not OUTCOME.
If the first story is more difficult, it should need more cost to implement.
I make sense to be estimated to more points than the other.
Though the people who will perform the work make the final estimate, you can coach them to approach a reasonable estimating.
Your estimated results may be associated to 3 possibilities.
1. The first User Story is indeed more difficult.
Convince the DT to increase the story points to the User Story.
2. The DT will acquire technology knowledge from the experience of implementing the first User Story.
A knowledge acquiring stage is common to most projects.
As your project is small, 2 sprints, it does not make sense to compare the 2 sprints’ velocity.
3. There are architecture, infrastructure, and/or others non-functional requirements implemented with the first User Story.
Convince the PO to decomposes the non-functional requirement as separated items so that they may reflect the real cost of each User Story.
PS:
It the Web serives mean "XML Web Services", Web API, for accessing by other applications.
There may be 3 user roles in your product. Application Developer, System Operator, System Admin.
Inspect your User Stories, maybe you can find something ignored.
> If we keep these estimations the team will
> probably do two stories during the next sprint
> (10 points) and the five others in the second
> (25 points) and the velocity of 25 will be wrong.
It doesn't strictly matter, because you are delivering value and not story points.
The purpose of estimation is to help a team forecast how much work it can take on in a Sprint. If the team reckons it can probably do two stories during the next sprint (10 points) and five others in the second (25 points) then estimation has served its purpose...even if the numbers are known to be wrong.
However, if story pointing is good, then the estimates can help the PO to order the Product Backlog. Each story should be pointed in such a way that it reflects the relative team effort that will be needed. Remember that the estimates given to Product Backlog Items should also take the proposed order into account.