Have you ever been sitting in a sprint planning and heard the following sentences:
“Can we split this user story and at least start with the GUI?”
“I’m not sure if the hardware will be available on time to integrate this story but we could use an emulator instead.”
“There are no wire frames yet, but we could start with the back-end.”
“The acceptance criteria are still quite vague, but I think I know what the customer needs.”
Does some of these sentences sound familiar? I observed these conversations several times in the past. All of these quotes are based on the same problem: The user story is simply not ready for the next sprint.
Half a year ago I wrote a blog post about 7 Agile Sins. As I’m sure, that I’m not the only one who is guilty for one or more of these sins, I collected a list of possible ways to show penitence and to do it better next time So here is my list of the sins and their appropriate penitence.
The first way for showing penitence is to help to create a learning environment in your company. One possibility to do this is to introduce so called brown bags. This is at least one corner stone to foster learning and bring new ideas in your working environment.
It’s about time for a new list. Today, I decided to write a list on how to mess up your retrospective. There are a lot of possibilities to do this and the following tips will help you doing so 😉
1 – don’t prepare anything
As the retrospective is the simplest and least important meeting of all Scrum meetings, it doesn’t need any preparation. Just come together and start. Wait, where are the pens and the post-its? Forget about it! Just sit together and chat a bit.
2 – Start immediately
As there is no need to set the stage, start immediately with gathering data. Immediately start the retrospective with asking the two questions: “What went wrong?” and “What went well”. That should be sufficient to get great results.
I continue to read and had to agree with him in many points. The rest of the week I kept thinking about this and came to the conclusion that in some environments a product owner team would be a better fit. But what could be a good reason for a product owner team?
1 – Responsibility
One good reason might be a shared responsibility. In some companies it seems to be difficult to define THE one and only PO with all needed responsibilities. Even worse, I saw product owners, whose decisions were overruled by their bosses and managers. This does not only have a demotivating effect on the PO, but also the development team becomes insecure when working with her. When you have a PO team, it is much more difficult to overrule them.