Web application development and Story Points

In your question you already mentioned the possibility of missusing the concept of story points:

"Java Developer can't estimate fronted work, and designer can't estimate logic layer, so they can't estimate all work."

Story Points are not there to estimate work, the are there to size how big a story is related to other stories in this particular context (project/team)

So also the storypoints do not rely on who/how many developers are on this.

When you use story points as they are (in my opinion) intended you estimate just how big the story is and use your velocity to determine how much you can achive within a sprint (Mike Cohn explains it very well, check out: estimate size, derive duration)

BR
Philipp

We are a web application dev company as well. Plus we have the added complexity of being a custom dev house which means that our clients require a formal quote with features and a timeline. But I won’t get into that here.

This is how we do it as an example. I have used your example but we also use the additional “So that <value>”

PBI: As a Customer I want to add a Product to my Shopping cart So that I can purchase the item.
This could get 8 story points.

If we were then going to select this for the next sprint, then the DT would split it up into tasks which a member of the DT would sign up for. These small tasks can then be assigned hours if need be but these should not be considered a commitment in anyway.

So the Developer would say that the one task to be done is "implement business logic" and estimate 8 hours and the Designer would add “we need to decorate view” and estimate 4 hours.

But the point is to not use the 12 hours (8 + 4) as a commitment to the client.

So to answer your question of “How to change it to final, summary estimation?” you could do the following.
1. Add up all the story points
2. Divide them by the Team Velocity
3. This would give the number of sprints needed
4. Then use that figure with the length of your sprints to calculate the number of weeks needed
5. If you know your team cost, you can then also use that to calculate a project cost

But be careful, you are standing on a slippery slope. This approach can very quickly become a “In Time, In Budget, In Scope” promise.

> I wonder how to give final estimation to customer when User story needs to
> be handled by more than one person.

Can you clarify why the customer wants a "final estimation"? In Scrum, estimation is done simply in order for a team to forecast how much work they can take on during a Sprint, and to better inform the Product Owner about the work that is likely to be remaining.

> I know that there shouldn't be some kind of specialisations of developers
> and DT should release increment after Sprint

It's actually the Product Owner who decides whether or not to release an increment, as he or she is responsible for the Return on Investment. The Development Team *deliver* an increment to the PO.

> but in my opinion - this is impossible in Web Application development proces.

Other web teams around the world manage to achieve this regularly. One approach is to handle the elicitation of UX requirements (such as wireframes) during backlog refinement in advance of the next sprint. This can be done by the team itself, assuming they have the expertise to do so. Alternatively those requirements can be gathered by the PO separately, and in advance of presenting the associated Product Backlog Items to the Development Team.

In either case, there is only one team involved in the estimation of work, since the UX requirements will be provided in advance of this estimation.

> Firstly Designers has prepared some designs, so DT before start any sprint, will have ready designs.

What a Development Team really need are actionable requirements with clear acceptance criteria that can be brought into a Sprint Backlog. Wireframes are one way of decoupling the visual information behind such requirements from the UX decisions a development team will make once a sprint has started. The difference between requirements-oriented "wireframes" and a "design" may seem subtle, but it's an important one to grasp.

Posted By Justin on 16 Apr 2014 06:07 AM
We are a web application dev company as well. Plus we have the added complexity of being a custom dev house which means that our clients require a formal quote with features and a timeline. But I won’t get into that here.

This is how we do it as an example. I have used your example but we also use the additional “So that <value>”

PBI: As a Customer I want to add a Product to my Shopping cart So that I can purchase the item.
This could get 8 story points.

If we were then going to select this for the next sprint, then the DT would split it up into tasks which a member of the DT would sign up for. These small tasks can then be assigned hours if need be but these should not be considered a commitment in anyway.

So the Developer would say that the one task to be done is "implement business logic" and estimate 8 hours and the Designer would add “we need to decorate view” and estimate 4 hours.

But the point is to not use the 12 hours (8 + 4) as a commitment to the client.

So to answer your question of “How to change it to final, summary estimation?” you could do the following.
1. Add up all the story points
2. Divide them by the Team Velocity
3. This would give the number of sprints needed
4. Then use that figure with the length of your sprints to calculate the number of weeks needed
5. If you know your team cost, you can then also use that to calculate a project cost

But be careful, you are standing on a slippery slope. This approach can very quickly become a “In Time, In Budget, In Scope” promise.

Yes completely agree with you. In order to achieve the goal of the business, first planning is very essential. Before implementing various elements in the business, estimation is also very important of all these elements