Help estimation problem

Hi Anthony,
I'm a little confused.

Posted By Anthony Sargento on 14 Sep 2015 04:39 AM
They are also independent. We have estimate each one to five story points but we know that the first one will be more difficult to do.

Posted By Anthony Sargento on 14 Sep 2015 04:39 AM
The Product Owner can't change the priorities and we have insert a dependence between stories but the velocity remains normal.

To discuss a solution, I prefer to discuss the problem first.

the first one will be more difficult to do.

Do you mean anyone story implemented first will take more effort than the others implemented later?

If you think your user stories are good stories, Ian have gave you a good answer "It doesn't strictly matter, because you are delivering value and not story points." in another topic you posted.

In many real cases, the stories selected for the first sprint must be independent when the DT counts velocity. Consider all work during the Sprint is on the user interface, or most of work during the Sprint is on knowledge acquiring, we would not want to extrapolate the velocity of that Sprint onto all remaining Sprint.

On the chance that you’d like to review your User Stories, let’s say the size of the first story is X and the size of the others is Y for each.
1st Sprint: X+Y
2nd Sprint: 5Y
X+Y = 5Y
X = 4Y

It does not make sense to set the size of each stories as the same.

I recommend to refine your Product Backlog items.

Not only User Stories, the Product Backlog lists all features, functions, requirements, enhancements, and fixes, etc.

You have not said the reason why the first one is more difficult, but the DT estimate each one to five story points.
So I guess the 7 Items have similar size but the DT need more time to implement the one selected first.

To the extent the first story will deliver some customer value or will involve the architecture implementation that may be used by the other Stories, I recommend conducting a cross-cutting design and add an independent Story for these work.

To the extent the DT are not familiar to Web services development, you may choose to add an independent PBI like this:
Investigate web services development.

Then, your will have 8 PBIs.
For example, the new item may be estimated as 6 points.
The 7 PBIs may be estimated as 2 points for each.
The velocity for each Sprint is 10.


Just for your reference.

Hi,

The first story is more difficult because it's the first and the team doesn't know the difficulties about adding a webservice in the project. I agree with you that adding a story to investigate is a good idea to estimate the others.

I don't like having seven stories in the backlog dependant of the investigation because you can't do both in the same sprint. Imagine after the investigation you learn that it's very difficult to add a web service you will have to remove some stories of the current sprint.

This question is just the easy one of the project. The real problem is that our client want to set a price on a story point and he is giving too much attention to the velocity. I know goal of the velocity is to help the team to estimate the work to do but he is using it to track the team productivity and pay in consequence.

Do you have some suggestions on how to manage the cost of a scrum project with commitments ?

Thanks for your answer.

PS: the other post is a duplicate of this one sorry !

I don't like having seven stories in the backlog dependant of the investigation because you can't do both in the same sprint.

Spikes are very normal part of software development in general as nobody can possibly keep up with or know about all technologies.
A time-boxed spike is a good practice to be integrated to the Sprint.
That means you can limit the time of knowledge acquiring and reserve enough time for functionalities development.

the team doesn't know the difficulties about adding a webservice in the project.

So, without conducting a Spike, what does the estimataion of 5 points means?
In the fact, there are chances the DT will increase the estimated size after the Spike.
It indeed makes sense.

Do you have some suggestions on how to manage the cost of a scrum project with commitments ?

Estimating is "forecast", not "commit".

For a contracted project, you can use "VALUE" delivered to trace the progressn and set the price.

In addition to story points, I always add set a VALUE to each User Stories.

value = knowledge value + customer value

For example, the knowledge value for the spike is 100, and the value of a web service is 50.
The output of the Sprint one is 100 + 50*2
The outcome of the Sprint one is 50*2 (for customer)
The outcome of the Sprint two is 50*5

For the Scrum team, the cost to create 450(100+50*7) points of VALUE is 20 points (6 + 2*7).
The value delivered to the customer is 350(50*7)

I'm not a well-trained Scrum practitioner, but have ground experiences.

Just for your reference.

> The real problem is that our client want to set
> a price on a story point and he is giving too
> much attention to the velocity. I know goal of
> the velocity is to help the team to estimate
> the work to do but he is using it to track the
> team productivity and pay in consequence. 

Well, the team could just increase their story points and pocket a tidy sum. And if that still isn't enough to satisfy his demand, I can supply your client with as many points as he wants at a dollar each, with my compliments.

Seriously though, you are right to identify this as the problem. It's therefore important to get to the cause:
- Why is the client so concerned about points as opposed to the delivery of actual value?
- Is your client really the end customer? Or is this person a middle-man who is demonstrating poor product ownership on behalf of other stakeholders?
- If value is so hard to determine empirically that story points end up proxying for it, why is this product or service being delivered at all?

The product is for a big company and it's the process for all scrum project with this company :
1. They search a scrum team from another company to build the product.
2. They ask the cost of one sprint.
3. We run three sprints.
4. With the velocity and the cost of the team they calculate the cost of one point.

After that they pay only for completed stories.

It's really strange and it's for that I want to talk about how to sell a scrum project but based on commitments.
With their process and with a first estimation of all stories they have an estimation of the cost of the project. After that if the velocity slow down they don't really care. The project will finish late but they don't loose money.

Complicated situation...

Could I conclude your problems as follows?
1. The story point is misused as the business day or man-hour to calculate the cost.
2. Your team does not have deep understanding or knowledge about the technology and problem domain of the product.
3. There are competitors so that you'd not like your customer know your technical issues.

With their process and with a first estimation of all stories they have an estimation of the cost of the project.
After that if the velocity slow down they don't really care.

Fortunately, this is a project of fixed scope, fixed budget(from the customer point of view), and flexible date.

Exactly !

If you'd not like to use the term of "Spike" or "knowledge acquiring", you may regard it as a work of architecure design and implementatiion.

For example:

Sprint 1:
Shared architecure disign and implementation. -> 6 points
Web services 1 -> 3 points

Sprint 2:
Web services 2 -> 3 points
Web services 3 -> 3 points
Web services 4 -> 3 points

Sprint 3:
Web services 5 -> 3 points
Web services 6 -> 3 points
Web services 7 -> 3 points

Though most of the work during Sprint one is a knowledge acquiring, these is at least one web service to be delivered.

Just for your reference.

> It's really strange and it's for that I want to
> talk about how to sell a scrum project but
> based on commitments. 

A Scrum Team may reasonably commit to a Sprint Goal. Note that it wouldn't commit to a Sprint Backlog, as that is just a forecast of the work needed to meet the Goal. Nor would a team commit to delivering story points as those are merely tokens to help the team make the forecast.

A more sensible approach would be to continue funding the team per sprint. As long as Sprint Goals are met then funding may continue until sufficient value has been delivered. If they aren't being met then the client has the option to cancel any future iterations. If the Sprint Goals aren't valuable enough to allow such a system to be applied then there is a deeper problem to be remedied.

Posted By Ian Mitchell on 18 Sep 2015 02:46 PM

A Scrum Team may reasonably commit to a Sprint Goal. Note that it wouldn't commit to a Sprint Backlog, as that is just a forecast of the work needed to meet the Goal. Nor would a team commit to delivering story points as those are merely tokens to help the team make the forecast.

A more sensible approach would be to continue funding the team per sprint. As long as Sprint Goals are met then funding may continue until sufficient value has been delivered.

For a Scrum Project, I 100% agree with Ian's expert point of view.

Sometimes, it does not workable for a contracted project.

A contracted project is usually fixed-scope, fixed-budget, fixed date.

Fortunately , the release date is flexible.

This is not a Scrum project, but a ScrumNot.

From the business point of view, you must commit the scope and budget for you client.

But for yourself, the Scrum Team, I 100% agree with Ian's expert point of view.
That means the budget should be flexible.

While the gap between the fixed budget and the flexible one is your business risk.

The problem may be narrowed to how to add the risk factor to each Sprint cost.
This is your BUSINESS[/B]

When scope is fixed the rationale for adopting an agile approach is weakened. The product can no longer be inspected and adapted.

It may be better to see this as a waterfall project and to plan and budget for it accordingly. If risk is low (i.e. the scope is unlikely to come under change pressure) then this may be the most rational approach. Any scope/budget changes that *might* arise, and which cannot be absorbed by flexing schedule or quality, would thus be handled in the classic waterfall way...i.e. by the change request mechanism.

Incremental delivery can still be supported, but each time-box would be a stage-gate to completion and not a Sprint. Scrum terms, which imply empiricism, should really be avoided.