The demo is an important part of the Sprint Review ceremony. However, there is a lot of contention who should run the demo, and how much preparation should go into it. Here are a few ideas to help make your demos more effective without decreasing efficiency.
We [the Agile community] value transparency and prioritization among many other things. We prioritize (or order) the most important things or the riskiest things to work on first. This is not new. What happens when it all is important or is all very risky or there is lack of clarity between the business and the team? Who has the final say in the priority of work items?
I’m going to start off by saying that I know Scrum and metrics don’t necessarily get along. But I will also acknowledge that it’s a necessary evil in most cases. And in a lot of cases it doesn’t have to be evil. Metrics are simply: a method of measuring something. In Scrum, we measure a lot of things. We measure the size of our work items, we measure the effort or time it takes to complete them. We measure our accuracy. All of this is in our quest to become predictable as a team and to improve (and we need to start with a baseline measurement to know if we’ve improved). But when others start taking notice of our metrics, that’s when things get tricky.
On a project I was ScrumMastering for I noticed much contention between many of the different roles on the team. In keeping true to Agile and Scrum we are supposed to be “cross-functional” but what does that really mean? I kept hearing “they’re not doing their job” and “that’s not MY job” in regard to requirements gathering, writing stories, and even bug fixes. There have been many pieces written on the roles of members of a Scrum team as well as many things written on cross-functionality of members, but what does that really mean and where do we draw the line to keep people accountable?