If you’ve got a traditional development hat tightly on, you might believe you’re done when the software is built. But Agile development and stories are built for learning. We spend a lot of time before we build anything making sure we should build it, and agreeing together on what to build. And, after we build, we’ll look again and ask if should have built it, and if it’s good enough.
Let’s talk about all the opportunities you have to learn after you build.
Let’s rewind to the celebrating part. At the end of a cycle of development and testing, celebration is in order. You’ve turned some ideas, lots of discussion, sketching, and hand waving into some honest-to-goodness working software. It would have taken a lot longer using a traditional requirements process. And you and your team would likely feel a lot less ownership of the result.
After a few high-fives, it’s time to sit down as a team and take an honest look at what we’ve accomplished. If we’re being honest with ourselves, we’ll likely find some things we’d change to improve the software. For each of those things, we’ll write another story and add it to our release backlog. We’ll decide if these are changes we need to make right away, or changes we can defer ‘til later during our endgame.
In processes like Scrum, this is called a sprint review. If you’re a Scrum practitioner, you may have heard that everyone is welcome at this review, but I’m going to suggest you do something ...