Blog Image


Agile - sharing experience

The idea with the blog is to share experience about Agile in practice, I have been facilitating CoP (Community of Practice) with Scrum Masters, Product Owners, Team members etc. since 2010 with the purpose of sharing learnings from team to team...

“Learn from the mistakes of others-you can never live long enough to make them all yourself.” quote from John Luther

PO presenting stories

Poker planning Posted on Thu, January 31, 2013 11:08:14

A common
challenge when the PO present stories to the team…

you happen to join a meeting with a PO who present “stories” to the team, the
PO have not created Story DoD for all (or any) stories and do not know details
about them.

The PO then
asks the team, “How long time do you think it will take to implement this”?

The team
will then try to get a better understanding of the story, what I often see is
that the PO does not know enough “details” about the story – there are in
principle 2 cases:

have a real customer – who request things, the customer decide and can be consulted

is creating something new and will deliver this to potential customers – i.e.
the case when we create features for mobile phones or SW for sale

We cannot
expect the PO to know everything, but the PO is representing the customer, so
the PO is responsible for driving the story DoD, there is a couple of ways to
mitigate the challenges

PO meet with the customer, bring along an architect (or senior team member) and
discuss the details with the customer, the PO and architect have probably had a
meeting before to discuss what they need request from the customer – after this,
they can come to the team and ask them to estimate…

PO meet with an interaction designer and architect (or senior team member) and
identify what is unclear – together they can come a long way in describing the
story DoD and be well prepared before they take time from the team…

There is a
3. Scenario – when you have a PO with high technical skills, they are sometimes
able to collect and describe most of the story DoD themselves, without support
from architects, interaction designers etc. – and they can often make decisions
on the spot without consulting anyone.

It is
a good idea to have a large post-it (I use super sticky from 3M, 200mmx149mm)
with each story before you as a PO meet with either the team, the Architect or
others – and then update the post-it with all the discussions you have, i.e.
layout, screen size, how to verify etc. – any picture is a great help for the
team, it makes things much easier to understand….

The most
important thing is that the PO understands, that the PO is responsibile of driving
the story DoD, it may not be the PO who write the DoD, but the PO is the voice
of the customer, so the PO must secure that the story is created according to
the customers’ expectations.

PO are usually better prepared, they know what the team want to know and prepare
most of it up-front, to keep the meeting with the team at a minimum.

And when it
comes to Story DoD – I sometimes get the response from the PO : “But creating story DoD takes way too much
– I can only say that if the PO do not believe that writing a story
DoD (max. ½ hour, often less for experienced PO) is worth the time, but the PO
expect the team to use 10-20 hours to implement it – then there is probably
something wrong in the way that the company prioritize the PO’s time.

And as
always – just in time – i.e. the PO should secure that there is enough info for
each story when the team need to estimate it (i.e. poker planning), it is
usually not a good idea to use time to create stories with detailed DoD for
coming 6 month – a backlog should contain the stories for the coming sprints (we
use 16 weeks, 8 with story DoD and remaining 8 with fairly detailed stories) and
epics (high level stories) for requirements after this.

Purpose of poker planning

Poker planning Posted on Fri, November 23, 2012 21:53:40

I remeber that I asked a team about the purpose of “Poker planning”, one of the team members answered, I believe that he thought it was a trick question, i.e. his answer was “to assign story points to stories”…

The answer is hower not the real purpose of Poker planning, the real value in poker planning is to ensure that each team member (including PO) have the same understanding of each story and know the scope of it; when the team members estimate the story, they often show that there is a gab in the understanding of the story and there is a valuable discussion afterwards, example is when you have a story where you on a web-page want to save some information and use it again, you may have someone estimating 1 point and someone saying that it is 20 points, each are perfectly correct according to their understanding. The person with 1 point will create a file (cookie) where you temporary save the information, where the member guessing on 20 point want to create a database on the server with a complex and very scalable system – both could be right, but the PO and the team have to discuss and agree on what they want to do…

Another value is that the PO gets information about the size of the stories, a story should never be so big that you cannot implement it in one sprint, if the PO find that one story is so big, the story have to be broken down to smaller stories.

One could argue that stories with very good DoD (Definition of Done) will never have this kind of miss-understanding; I have however only seen very few DoD which are so good that the team will not have a different understanding, and there could still be a clearification about what the PO want to achieve.