AgileInPractice

AgileInPractice

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 planningPosted by Rune Hvalsøe Thu, January 31, 2013 11:08:14

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

Sometimes 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:

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

2. PO 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

1. The 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…

2. The 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.

Experienced 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 time” – 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.

  • Comments(0)//agileblog.danskerne.se/#post16

Purpose of poker planning

Poker planningPosted by Rune Hvalsøe 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.

  • Comments(0)//agileblog.danskerne.se/#post0