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!


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?

To get the basics of agile software development right, visit my online course. If you want to keep up with what I'm doing, follow me on, LinkedIn or twitter. Or visit my GitHub project.