Before I start talking about some nasty Scrum stuff, first let me introduce myself: My name’s Andreas Hofmann, born *86 and working for Turtle Entertainment since January 2011 as a Software Developer. Since April 2012 I’m the ScrumMaster here at Turtle and since August 2012 I’m also the trainer for our “Fachinformatiker Fachrichtung Anwendungsentwicklung” trainees. We’re currently having nine developers (excluding me), including one trainee and two externals working in one team (I think I will write our experiences with multiple teams in a later post).
But I want to tell you something about our own Scrum modifications in this and the next posts to come. You should always remember one of the most important facts about Scrum:
The Scrum process is free to be modified!
If there is something that doesn’t work for your company or if you have a new idea: Do it, change it, improove(!) it! But share it with the world, so everyone knows about your experiences!
So in this post I want to talk about the Story discussions we have established.
What was the idea/the impulse?
Well, in some Sprintplannig 1 and some estimations we figured out, that there can be problems with the stories for the developer side as for the product owner side.
For the development side there was
- Problems understanding the story itself: What should really be done?
- Further questions, most in detail: What if and how this and how that?
- Figured out that a UI is needed for a story and it wasn’t present in the SP1!
- So: Story can’t be estimated and it’s therefore a 100!
So you can guess the problems for the product owners:
- Stories are not estimated (=100) so they can’t plan properly!
- Stories are not committed because of missing requirements, UI for example!
- And this all leads to a messed up planning for the POs and/or the management!
- Sometimes a PO needs help from the developers to write a story correctly because he’s missing the required technical knowledge to write the story in the way it can be estimated!
You may say:
- “Open questions? The SP1 is the place to clearify them!”
- “Stories are not clear enough? So the POs failed in their work!”"
Maybe! But you have still the missing requirements left and and the missing knowledge! And there are more positive things you will get, if you read further:
We thought: Hey it would be a great idea to talk about stories before seeing them the first time in the estimation and say: WTF!? So we established the storydiscussions which are taking place when there are new stories written or new facts for an existing story.
The timebox is 1 hour. Allowed members are the team, the PO(s), the ScrumMaster and sometimes special guests like the stakeholder to explian the need in more detail or developers from other companies to work with for a particular story.
Participation of each team member is optional, they are not forced to go there, but it’s in their own interest: If there is a problem, it might be unseen by another developer! Your ScrumMaster job here is to get people there but not to many. We found out that 3-5 teammembers is a good number. And you should mix the devs who are going!
The PO now presents one story and the discussion/questioning is open. Every dev can ask questions, make reservations that something might not work as intended in the story or maybe it’s totally impossible to do. Or he’s just giving feedback. The PO writes down all questions/answers, feedback and refines the story after the meeting to present a more detailled and clear version to the next estimation meeting! The PO can discuss as many stories he wants but remember: timebox!
Your job as a ScrumMaster is also to watch that it’s not getting out of hands: Sometimes you have very “enthusiastic” team members that try to tell the product owner his job and how he should design the product/story. They can make recommendations or reservations but it’s not their job to design the product!
So what do you get?
- More detailled stories!
- Less 100-stories in estimation meeting!
- A team which feels more prepared for a story and knows everything it needs to know about!
- The team can detect stories where they might have to do some evaluations on them first before they can be comitted! Imagine this would be revealed in SP1, when the story is discussed! That would lead to an horrible SP2 of two days and frustrated devs and POs (and therefore a frustrated SM) or they won’t commit it!
- All required ressources are present: UI, hardware, software, etc.
- Overall you will get a more motivated team and POs who are feeling more safe in their work!
For sure, we are not skipping the discussions in SP1, but they are getting smaller! There will be questions again, but you will reduce the suprises to a minimum!
Hopefully that was helpful to you! Please leave some feedback if you have any :) Thank you for reading!!
Author: Andreas Hofmann