Print Retrospectives - Overlooked and Undervalued

The Sprint Retrospective is probably the least valued of the 5 events in Scrum. Like the stereotyped middle child, the Sprint Retrospective is often forgotten or skipped in return for precious time that could be used writing code. But the fact that it is one of the few carefully chosen events in Scrum and endorsed and taught by Scrum coaches and practitioners, should perk our ears and motivate us to pay attention to and perfect the art of the retrospective.

So let’s discuss why this deserves to be put back into the limelight.

Like a middle child, the Sprint Retrospective is often forgotten or skipped

Sprint Retrospective Goal

The purpose of the retrospective is, as its name implies, to look back or reflect on the last Sprint. It’s an opportunity for teams to brainstorm and discuss events and processes that are working well and those that are not, for the purpose of improving the efficiency and effectiveness of the team. Discuss the likes and dislikes of the team. What works and what doesn’t. Cover as much ground as you can, including the Scrum process, stories, the definition of done, deadlines, culture, people, communication and whatever else that’s on their mind. The Scrum Master’s responsibility is to tactfully manage, guide and participate in these discussions such that everyone’s feedback is taken into consideration and resolutions are worked out.

Agile User Stories -Your Tool for Getting the Software you want.

The developers who build your custom software have many skills. Unfortunately, mind-reading isn’t one of them. To this end, the Agile methodology has a way of getting the thoughts from your head and delivering them to your Agile development team. Agile user stories are not technical requirements; they are a way to describe the value that the end-user will get from the software.

What is an Agile user story in the Agile Methodology? A user story is a software feature from the actual user’s perspective. It will include who the end-user is, the feature, and why they want it. It is a description of a requirement formulated in a way that the end-user will immediately identify with. User stories most often (but not always) follow a simple formula:

• As a {type of user}, I want {some goal}, so that {some reason}.

• As a CFO, I want drill-down divisional sales graphs so that I can easily go from high-level results to granular figures.

• As an online shopper, I want an easy login screen so that I can easily complete my purchase.

• Agile user stories should be the starting point of a discussion and can be used to populate the product backlog.

Why are user stories critical to your project’s success? User stories ensure that the developers working on your software understand the way that you will use the software. Furthermore, it allows them to improve the way you work. ​ As Samuel Khew from Suria Labs says, “User stories are critical because they are the primary bridge between the customer and the developer. It’s a time game. Get your story right, and it’ll be done right on the first go. ​ Get your story wrong, and you’ll lose time in feedback loops or worse, having to re-do the feature.”

4 Tips for creating brilliant user stories.

• Have the user at the center of your story: This seems obvious, it is, after all, a USER story, but it can be very tempting to make this a technical specification. That is why you should always start by clearly identifying the end-user. Once you have nailed down a specific person, or persona, it is much easier to ensure that you describe how the feature will add value, not just what the feature is.

• Your user story should be as simple, specific, and concise as possible.: A great user story is as long as it needs to be and no longer. Add anything that improves clarity, and nothing that doesn’t.

• Have clear acceptance criteria: What does it take for your user story to have a happy ending? What are the clear deliverables that define that the feature delivers the described value to the end-user? Add as many acceptance criteria as necessary. These add color to the story, and also makes an associated release easily testable.

• Review and refine your user stories through conversations.: Remember that an Agile project thrives on great conversations. Don’t assume that you have your Agile user story 100% perfect on your first attempt. As you progress through the project, make sure you are checking in that your user stories are still valid, still clear, and the value that they describe is still of importance. Agile was designed to accommodate change so, therefore, be open to adjusting or even discarding user stories that no longer describe actual value. Over the life of your Agile project, it is possible that business direction will change. Furthermore, it is almost inevitable that your understanding of the software will change.

Conclusion As a customer, you want your custom software development project to deliver the maximum value to you, in the minimum time, at the lowest possible cost. Working with your team to create great Agile user stories will ensure that the entire team can apply laser focus to the things that matter most to you.