Skip to main content

Story estimation problem

Last post 01:07 am September 15, 2015 by Ian Mitchell
2 replies
11:17 am September 12, 2015

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.


10:21 pm September 14, 2015

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.


01:07 am September 15, 2015

> 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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.