Scrum - the hard parts

#scrum #agile #humor

The hard parts of Scrum and how to work around them. Further inspiration can be found here: ScrumBut.

Only the developers estimate

According to the Scrum Guide, only members of the development team are allowed to estimate development effort. Neither Scrum Master, nor Product Owner.

As a Product Owner, you should therefore subtly influence the estimates in your favor by asking questions like: "You can do that in two weeks, right?" Or: "I can't imagine that this is a lot of effort. Does anyone else see that?"

That way, you stay in control even when the going gets tough!

Done

Scrum calls for a potentially shippable product increment at the end of a Sprint: executable, tested and integrated software. Because this is one of the hardest parts of Scrum, there are several workarounds to make life a little easier.

First, learn to appreciate other artifacts as Sprint results as well. How about a completed analysis or architectural document? For this to work, you only need to adjust the Definition of Done.

Second, most importantly: do not forget the phases before Scrum and after Scrum.

Before Scrum, a planning phase of several months should take place, in which the project is approved and its scope is fixed.

After Scrum, you should have a test phase of at least several weeks until the product can finally be delivered. This workaround is particularly useful if you do not use any form of automated testing, integration or deployment.

The product owner sets priorities

According to the Scrum Guide, the Product Owner has the final say when prioritizing the Product Backlog.

This is uncomfortable. It would give the lower level management folks huge decision-making power. Real managers keep away from developers, in order to be able to make unpleasant decisions and enforce them.

Fortunately, there are now established roles such as the "Proxy Product Owner". Rightly applied, that role has no decision-making authority. PPOs merely pass on the announcements from the top to the developers and "take the responsibility" if something goes wrong.

So - these are my "recommendations" for you today.
What are your favorite Scrum hacks?

This article originally appeared in German in the HOOD blog