Loading ...
Sorry, an error occurred while loading the content.
 

Re: [scrumdevelopment] How well understood should a PBI or User Story be at various points in its lifecycle?

Expand Messages
  • Markus Gaertner
    I am quite certain there is no one size fits all answer to this question. Here is what I see helps most teams I encountered in the past years. At sprint
    Message 1 of 60 , Jan 7, 2013
      I am quite certain there is no one size fits all answer to this
      question. Here is what I see helps most teams I encountered in the
      past years.

      At sprint planning that story should be understood well enough so that
      the team can break it down into work items, i.e. tasks. That does not
      mean that there won't be any confusions during the sprint - quite
      contrary, but that's why an onsite customer like the product owner
      helps to clarify those misunderstandings.

      With that goal in mind plan toward your sprints. What do you need to
      have in order to reach that understanding? Most teams these days seem
      to do a mixture of specification workshops where the team identifies
      acceptance criteria in an executable manner, and backlog grooming
      meetings where the stories are estimated and clarified.

      After all, keep the 3Cs in mind: card, conversation, confirmation. The
      confirmation part are the acceptance criteria, and you need to have a
      conversation for that, since not all the details will fit on the
      physical card. And if the team does not feel confident about using
      that particular in the next sprint, then it might be an indicator that
      it's too large and needs to be split up - in the grooming meeting.

      Best
      Markus

      On Mon, Jan 7, 2013 at 9:34 AM, Kurt Häusler <kurt.haeusler@...> wrote:
      > Hi,
      >
      > I guess this discussion is slightly specific for teams using User
      > Stories as PBIs, but could also be relevant for other teams using
      > other types of PBIs. So I will use the term User Story in this
      > message, even though I know it is not a Scrum term.
      >
      > Background: We do too much analysis outside the sprint, producing word
      > documents and mockups and attaching them to "user stories" in Jira,
      > with the downsides that they prevent discussion in the sprint, get
      > outdated, or get thrown away and represent wasted work should the
      > story get removed from the backlog. This question came from the team
      > when I was explaining how user stories are placeholders for a
      > discussion.
      >
      > The Question: How well understood should a Story be at various points
      > in its lifecycle?
      >
      > I guess at the beginning, when it is first placed in the backlog it is
      > not very well understood at all, at least by the team. Lets call this
      > 0% understood.
      >
      > During the sprint someone should take the user story and talk to
      > someone and achieve sufficient understanding to begin developing it.
      > Lets call this 100% understood.
      >
      > At some point though the story has to reach a definition of ready
      > while it is still in the backlog. It has to be small enough for the
      > sprint, and it should have all its acceptance criteria. The team
      > claims this requires it to be about 90% understood, and that all these
      > word docs and screenshots are just part of the process for getting it
      > well enough understood for the definition of ready.
      >
      > Then you have a planning meeting where, at least in typical scrum
      > teams, the story should well enough understood that the team can begin
      > discussing a solution, or the actual work involved to implement the
      > story. Perhaps the team will even begin to write down a list of tasks
      > to be done. The team claims this requires the story to be about 99%
      > understood. And any information required has to come from somewhere,
      > so it better to have it in those handy documents.
      >
      > They then ask, is this conversation that is supposed to take place
      > really only to discuss this last 1%? Is it really worth having?
      >
      > I started to explain the other extreme as being ideal, i.e. it only
      > needs to be about 10% understood to be ready for the sprint, and it
      > only needs to be 20% understood to be planned by the team for the
      > sprint, and the discussion is important for the last 80%.
      >
      > I wasn't sure though.
      >
      > What sorts of things are known about a story at these various points?
      > What is really left unknown that can only be cleared up by the
      > discussion, after the task breakdown?
      >
      > Any ideas about how I can explain this to the team?
      >
      > Cheers,
      >
      > Kurt
      >
      >
      > ------------------------------------
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
      >
      >
      >



      --
      Dipl.-Inform. Markus Gärtner
      Author of ATDD by Example - A Practical Guide to Acceptance
      Test-Driven Development
      http://www.shino.de/blog
      http://www.mgaertne.de
      http://www.it-agile.de
      Twitter: @mgaertne
    • avinap77
      p.s. While we re at it: The ScrumMaster acts as a coach for the Scrum Team, helping them to execute the Scrum process. He helps them to work together and to
      Message 60 of 60 , Jan 12, 2013
        p.s. While we're at it:

        "
        The ScrumMaster acts as a coach for the Scrum Team, helping them to execute the Scrum process. He helps them to work together and to learn the Scrum framework, and protects them from both internal and external distractions. **He may facilitate meetings**, and helps keep the Scrum Team on track, productive, and growing in ability.
        "
        (Agile Atlas, I think you know which page)


        I'm in fact addressing the root cause of this discussion - here:
        https://trello.com/c/fZQC4KfI

        Have a happy week,
        and don't take me too seriousely - I would be deeply offended if you did...

        Avi

        -------------
        We're not building nuclear missiles, nor promoting world peace.
        It's just software, Try to remember it.


        --- In scrumdevelopment@yahoogroups.com, "avinap77" wrote:
        >
        >
        > Healthy sense of self-humor helps too..
        > ;-)
        >
        > With greatest respect, Really.
        > Avi
        >
        >
        > --- In scrumdevelopment@yahoogroups.com, Ron Jeffries wrote:
        > >
        > > Hi Avi,
        > >
        > > On Jan 12, 2013, at 5:21 AM, "avinap77" wrote:
        > >
        > > > So what's the deal with facilitation? is it in or out?
        > >
        > >
        > > You win. The word "facilitates" appears in the Scrum Guide.
        > >
        > > Ron Jeffries
        > > www.XProgramming.com
        > > I have two cats, and a big house full of cat stuff.
        > > The cats fight and divide up the house, messing up their own lives.
        > > Nice work cats.
        > > Meow.
        > >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.