Requirements

"Ok, so Agile is a great way to develop software", you say, "but how do I sell it to my customers?". Most pricing models that I've seen don't balance risks fairly between the customer and the supplier. Either the customer or the supplier carries all the risk, which doesn't sufficiently push both parties to take their responsibility. In this post I describe a simple pricing model that I've applied succesfully, and that - I think - balances out risks more fairly. The 'fixed-price, fixed-scope'-model The 'traditional' approach is to agree upon a set of requirements with your customer, estimate the…

This is a re-post of an older post. This version has been revised and extended with more strategies. The downloadable cheatsheet has been updated accordingly. Teams that have mastered Scrum know that the key to success lies in a just-in-time, increasingly refined, breakdown of work on the Product Backlog. They prefer Sprint Backlogs with many small (functional) items instead of just a few large ones. Smaller items improve flow, and reduce the risk of failing the sprint. In this article, I will explain why the break-down of work is important, and why it should be done across functional - instead…

One of the biggest challenges for a Scrum Team is to switch from a technical to a functional perspective on their work. The former focuses on the 'how' of development - which components must be changed, what code is touched - whereas the latter focuses on 'why' and 'who' - what do we want to achieve and for whom are we building this software. The locus of these questions lies in the Product Backlog. Assuming that the Product Owner and the stakeholders represent 'business' and/or 'customers' (which they should), the Backlog should be readable by all. Not only for…