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.

Estimation & Planning
Last Post 20 Jun 2014 08:58 PM by VS Chandra Mouli Seelaboyina. 7 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
VS Chandra Mouli Seelaboyina
New Member
New Member
Posts:27
VS Chandra Mouli Seelaboyina

--
12 Jun 2014 10:02 PM
    Hi All,

    I've seen in some scrum practicing teams performing sprint planning without having backlog grooming. i.e Stories are not being estimated with story point. They are directly taking the story based on importance and asking team how many hours required to complete the story and what are sub-tasks. I strongly feel its not correct. most of the time the stories are customer defects and require research and analysis. I can say they are mixing the estimation and planning or bypassing estimation.

    Estimation should never mix with planning.Please share your thoughts on this.


    My understanding is a sprint planning meeting should have the following things to do:

    1. Calculate the team capacity
    2. Sprint Goal
    3. pick the stories based on capacity
    4. Task breakdown.


    Thanks
    Ilia Pavlichenko
    New Member
    New Member
    Posts:71
    Ilia Pavlichenko

    --
    12 Jun 2014 10:21 PM
    Scrum doesn't forbid making estimations during Sprint Planning. I would say this is usually the last point in time it can be done before actual work on the Sprint starts. Some teams in fact don't do any estimations at all. They are able to cut the PBIs of the equal size and estimation becomes reduntant. Some teams are able to do Sprint Planning so effectively that they don't need PBRs at all.

    Imagine a situation that after Sprint Review the Product Backlog is updated and PO decided to insert a new feature at the top of it. You don't have any time for PBR before the Sprint Planning.

    Capacity can be calculated as you wrote but is also can be thought of as a "gut feeling" of the team. It's not mandatory to be calculated in ours.
    Scrum doesn't prescribe using stories. It's just a good practice.

    There's no "correct" way of doing Sprint Planning. What you're talking about is just some practices. Some can be appropriate for the DT, some not. Follow the Scrum Guide defininion of the Sprint Planning.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1533
    Ian Mitchell

    --
    13 Jun 2014 12:21 AM
    > most of the time the stories are customer defects and require research and analysis

    If that is the case, would you say you have clear Sprint Goals? Remember that the goal is the purpose of the Sprint, and estimates are a means of determining how much work the Development Team can take on.

    As Illya says, some teams cut the PBI's to be of roughly equal size. That can be a viable research & analysis technique in its own right.
    Carsten Schuetz
    New Member
    New Member
    Posts:1
    Carsten Schuetz

    --
    13 Jun 2014 01:22 AM
    I agree with Illya as far as the PO's perspective is concerned. For me as a PO, I am responsible for the Backlog and wnat to have estimates as soon as possible on the one hand, but do also not want to disrupt during Sprints on the other hand.
    That is why we sometimes do estimations during Planning.
    Randy Ho
    New Member
    New Member
    Posts:47
    Randy Ho

    --
    13 Jun 2014 06:28 AM
    Estimates in the backlog serve two purposes:

    1) to determine priority. Since it is the PO's job to maximize ROI, he will need Effort vs Value in order to make a judgement on priority. The ROI calculation can be done at the epic level or story level depending on the needs of business.

    2) to do release planning. effort estimates in the product backlog in conjunction with velocity will provide a projection on future release(s).

    So long as the PO is able to maximize ROI and appropriately plan releases for the business needs, how and when estimation is done becomes a irrelevant.
    Olivier Ledru
    Basic Member
    Basic Member
    Posts:222
    Olivier Ledru

    --
    15 Jun 2014 06:51 AM
    For me, estimate is useful to convey the conversation among users / PO / dev team.
    The point is not about having "accurate" estimate, (is this PBI 3 or 5 points, and this one 8 or 5 ?) but having a good understanding of the PBI.
    It should be done before the Sprint Planning Meeting, in order to have enough time to discuss the 2 topics (what & how) & craft the sprint goal.
    If this is not done before the Sprint Planning Meeting, most of the time is spent one the estimates, and the "how" and the sprint goal are just skimmed.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:409
    Charles Bradley

    --
    18 Jun 2014 08:37 AM
    Mouli,

    What your team is doing does not violate Scrum, but they may be using practices that are suboptimal. So, while your team may be using the Scrum framework correctly, they have not yet optimized how they *implement* Scrum, or "fulfill" the framework.

    I'm a big believer in refinement (formerly called grooming), and my suggested practice is to get 2 sprints ahead on refinement.

    More here:
    http://scrumcrazy.com/bugs
    http://scrumcrazy.com/pbr
    VS Chandra Mouli Seelaboyina
    New Member
    New Member
    Posts:27
    VS Chandra Mouli Seelaboyina

    --
    20 Jun 2014 08:58 PM
    Thank you all for your precious suggestions and opinions
    You are not authorized to post a reply.


    Feedback