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.

Splitting up stories
Last Post 26 Mar 2014 03:33 AM by Chee-Hong Hsia. 6 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Pablo Rossi
Basic Member
Basic Member
Posts:181
Pablo Rossi

--
26 Mar 2014 12:25 AM
    As scrum master/coach, when are you triggered to coach teams (whom are new with scrum) to split up stories?


    Michael Mai
    New Member
    New Member
    Posts:4
    Michael Mai

    --
    26 Mar 2014 12:39 AM
    There are a number of indication:
    - If a team is inconsistent in its estimate. This means that the item is to complex to render a unified estimation.
    - If a item is estimated "big". "Big" in relation to the usual amount of story-point / item-point / t-shirt-sized / ... the team is able to deliver within a sprint. Rule of thumb: In a sprint a team should be able to deliver three or more items.


    If we a going to multi-team scrum:
    - If different teams cannot agree upon one estimate for a single PBI - assuming that the different teams had already found a common basis for joint PBI estimation. This indicate, that either the item isn't suited to be delivered by all teams (the customer feature, this PBI is addressing spans over multiple teams with very different team-profiles) and is therefore kind of pre-destined for only a small set of teams or the complexity is very different in the vertical slices.
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    26 Mar 2014 12:45 AM
    Has anybody made the experience that you split up stories, and in sprint planning the dev team clips them together again? It seemed kind of weird to me...
    Chee-Hong Hsia
    New Member
    New Member
    Posts:73
    Chee-Hong Hsia

    --
    26 Mar 2014 12:59 AM
    Inconsistency in the estimation is something very common I guess. It’s usually a sign that the story isn’t well understood (yet). In this case I would expect differences in estimation, let the team talk discuss it and hopefully come to a consensus, estimation-wise.
    Despite all of this, it still remain a best guess, because the reality is that the team have no clue in how big the story actually is.

    Usually what I do is set up a threshold with my teams. We agreed that all stories bigger than 5 points is considered a “really big guess” so the team needs to split it up. It’s actually crafted in our DoD as

    “Items can’t be bigger than 5 points to be included in the sprint”
    The best way to motivate your team is “to make a game out of it”.
    A “game show” where the team needs to split the stories up in the smallest possible way :)




    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1676
    Ian Mitchell

    --
    26 Mar 2014 01:13 AM
    Before a Development Team accept a story onto their Sprint Backlog, they must be satisfied that they can actually complete it. There's no point in a team trying to action a story if they know from the outset that it will only end up blocked. A common example is where the team do not fully own their process and will be dependent upon another team for part of the work to be done.

    If a story does contain such a source of impediment, it can be worthwhile splitting the story up into component parts that the team *can* action. For example, if a story will become dependent upon another team part way through, consider splitting it into "before" and "after" stories. The "before" story could deliver value to the other team (so they can do their part of the work) while the "after" story delivers business value to the client.

    This story-splitting approach allows a team to wrap impediments, and progress the work that they are actually in a position to do, when they are able to do it. However, it is not something to be done lightly as the value provided by "before" stories can become rather contrived. The more artificial the value being supplied to another team, the more likely it is that the associated capability needs to be brought in-house so the original story can be wholly completed.
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    26 Mar 2014 02:38 AM

    It’s actually crafted in our DoD as
    “Items can’t be bigger than 5 points to be included in the sprint”


    Isn't the definition of ready a better place for this? If you accidentally include an 8 point story and it gets done except the rule that it can't be bigger than 5 points, what do you do? You can never shift it to "done"...
    Chee-Hong Hsia
    New Member
    New Member
    Posts:73
    Chee-Hong Hsia

    --
    26 Mar 2014 03:33 AM

    Isn't the definition of ready a better place for this? If you accidentally include an 8 point story and it gets done except the rule that it can't be bigger than 5 points, what do you do? You can never shift it to "done"...


    Woops... my bad... I ment the Definition of Ready :)
    You are not authorized to post a reply.


    Feedback