Done? How Scrum Is Like Cooking A Steak
Well-done. Medium, Medium-rare. How do you like your steak to be done?
As long as it’s cooked right, and it comes from good beef, it doesn’t really matter to me what type of cut it is. It’s hard to beat the flavor and the juicyness of a steak that’s prepared the right way. But when I cut into a steak that hasn’t been prepared the way I like it, then I just cannot eat it. In general, this happens because my definition of “done” doesn’t match the preparer’s definition of “done.”
This problem can creep into your Scrum projects as well. In this post we’ll talk about what creates this problem and how to avoid this situation.
In Scrum, each iteration of the Sprint cycle produces a potentially shippable product increment. During the Sprint Review session, the Team gets the spotlight. They get to share with the stakeholders and the customer the work that they’ve completed over the last Sprint. If the expectations of the customer line up with what the Team delivered, then everyone is happy. But sometimes that doesn’t happen. The customer comes in to the Sprint Review expecting one thing but gets something else instead. So while the Team Members may agree that a particular feature is “done,” the Product Owner or the Customer may not.
In order to avoid this situation, here are seven tips to get you started:
- Have a fully engaged Product Owner. Because the Product Owner is the customer liaison to the team, they are the critical link in understanding what is most important to the customer.
- Create well-worded, specific User Stories. The best User Stories describe the role of the user/customer, what they want and expect from the product, and what benefit the feature brings. These are the easiest to translate into features for the backlog, and in turn become good requirements and tasks for the team.
- Ask questions. Don’t assume anything. It is ALWAYS better to find out early that your assumptions didn’t meet the customer’s expectations. If something is unclear, never be afraid to ask good questions in order to clarify what the customer wants.
- Estimate well. You might think this doesn’t have anything to do with feature completion. However, it is human nature to feel pressured to meet the estimates that we set for ourselves. A poor estimate can lead to rushed work, which in turn can cause a feature to not be completely done.
- Choose Product Backlog items wisely. By picking complementary items from the backlog, the Team has a better chance of success. If team members choose items that are all across the board, they may miss a critical dependency between items that may not be part of the current Sprint’s backlog.
- Keep you Product Owner informed on your team’s progress. Communication is critical, and if the team is struggling then the Product Owner needs to know this early on. In this way, the Product Owner can keep the customer and stakeholders apprised of issues that may not appear on the burnup/burndown charts.
- Test, test… and test some more. There is no substitute for determining if a feature is done other than comprehensive testing.
So that’s our quick and dirty tips for avoiding the question of “done.” If these aren’t enough, let Braintrust help! With our experienced team of Scrum coaches, Braintrust has all sorts of experience and resources available to help you know, beyond a shadow of a doubt, when a product is done. Click on the Contact page to hear from one of our product specialists. Or, head over to the Services tab to find out more about our offerings.
]]>
