Re: [scrumdevelopment] How well understood should a PBI or User Story be at various points in its lifecycle?
The goal of the planning meeting is to forecast what the team can accomplish during the sprint (capacity based or velocity based) and to come up with a plan for doing it (split user stories to tasks, identify initial impediments, etc.). Estimates, sometimes, can be useful in this case.
I assume the teams are also doing done sort of estimation (planning poker, t-shirt sizes etc.)
In my experience, the team should have a good understanding of a story, it's dependencies, risks, etc when they are estimating the story. It is hard to put a number, but what I can say is that the understanding grows over time.
Of course, we can say that they have understood it 100% only if their implementation is accepted by product owner, but thats just the extreme.
What I am hearing is that there is a lot if waste incurred by the team. Can you help them realize it? Also, in your opinion, what else is happening in the system(inside/outside the) team, which is making them say " we need to understand it 90%..."?
RamOn Jan 7, 2013 3: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
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?
- 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.