The Agile Pocket Guide: A Quick Start to Making Your Business Agile Using Scrum and Beyond

Chapter 22

Measuring a Working Product

One of the things a team needs to clarify for itself is what it means to be done. As team members continue along the Agile path, they are supposed to demo the product and then retrospect the sprint. The demo process signifies that the stakeholders have working software, product, or something they can use. But, let's be real here: there are times when you have a sprint that won't include a demo-able piece of software or product (though we talked about how this can be avoided in Chapter 14). Regardless, how do we measure that the software is working? Do we define it through the fact that our critical test paths work and the code is running? Maybe we should look into how we define working, or done.

One thing to take into consideration is how different teams define done. A developer will not have the same definition as a QA analyst, a database developer, or a systems or business analyst. To begin, sometimes it's easier to figure out what something is by first looking and defining what it is not.

One of the worst ways to measure whether something can be classified as working software is by meeting documented specifications. This may sound contrary to popular belief, but often the specifications have fatal flaws in them and the product may not exactly do what is necessary for greatest value to the business. Revenue is another way by which many companies measure whether the software is working; however, as I've found in the past, market fluctuations ...