Re: [scrumdevelopment] How well understood should a PBI or User Story be at various points in its lifecycle?
- 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
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.
On Mon, Jan 7, 2013 at 9:34 AM, Kurt Häusler <kurt.haeusler@...> wrote:
> 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
> 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?
> 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
- 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:
Have a happy week,
and don't take me too seriousely - I would be deeply offended if you did...
We're not building nuclear missiles, nor promoting world peace.
It's just software, Try to remember it.
--- In email@example.com, "avinap77" wrote:
> Healthy sense of self-humor helps too..
> With greatest respect, Really.
> --- In firstname.lastname@example.org, 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.