Forums

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. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

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.

Web application development and Story Points
Last Post 13 Sep 2014 12:57 AM by Dawn Gains. 4 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Bartosz Bobin
New Member
New Member
Posts:2
Bartosz Bobin

--
15 Apr 2014 01:28 PM
    Hello scrum fans!

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

    I know that there shouldn't be some kind of specialisations of developers and DT should release increment after Sprint, but in my opinion - this is impossible in Web Application development proces.

    Maybe I will describe how it usually looks in Web Application development:

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

    Than during Sprint We will have a User Stories, like .:

    As a Customer I want to add Product to Shopping card.
    So, we need activities from
    * Java/.Net Developers - to implement business logic,
    * we need to decorate view - so a lot of frontend developer work (mostly advanced knowledge of JS and it's components)

    Java Developer can't estimate fronted work, and designer can't estimate logic layer, so they can't estimate all work. They estimate their's parts as:
    * Java developer - 5SP
    * Designer - 1SP

    In other User Story - we can have another estimations:
    * Java developer - 1SP
    * Designer - 5SP


    my Question is:

    How to change it to final, summary estimation?

    My role - Java Developer.
    Philipp Eisbacher
    New Member
    New Member
    Posts:35
    Philipp Eisbacher

    --
    16 Apr 2014 02:00 AM
    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
    Justin Todd
    New Member
    New Member
    Posts:48
    Justin Todd

    --
    16 Apr 2014 05: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.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1493
    Ian Mitchell

    --
    16 Apr 2014 02:20 PM
    > 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.
    Dawn Gains
    New Member
    New Member
    Posts:1
    Dawn Gains

    --
    13 Sep 2014 12:57 AM

    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
    You are not authorized to post a reply.


    Feedback