Published June 26, 2023
by Doug Klugh
Avoid Focusing on the Team
Avoid this anti-pattern by building your product backlog with user stories that deliver value to your customers. Do not write “Team Stories” that represent development tasks that serve the team. Promote continuous delivery by ensuring that every card on the backlog delivers working software to your customer that they can use and evaluate. Early and frequent feedback is necessary to enable agility and to ensure that problems are truly being solved. Waterfall methods often fail because meaningful feedback is infrequent and late in the game. Development activities should be managed as tasks within user stories that are required to design, implement, test, and deploy that specific functionality. Enact YAGNI to ensure that development activities are just enough and completed just in time.
«
The story must have clear and quantifiable value to the business.
Refactoring is never a story.
Architecture is never a story.
Code cleanup is never a story.
A story is always something that the business values.
»
— Clean Agile: Back to Basics, October 2019 - Robert C. Martin
Do you use your scrum board and backlog to manage and track the work of the team? Or are they used to manage and track the value that is planned for the customer? The first (and most important) principle of Agile is to satisfy the customer. This is best achieved when the user is at the forefront and centre of the requirements, design, and validation.
To realize continuous delivery, every card on your backlog should have a deliverable to your customer. Every development activity should tie back to a customer deliverable — as a task within a user story. It makes no sense to “deliver” stories that only serve the team. That is why user stories are always written from the perspective of the user — to ensure we are serving the customer.
So… Does it not serve the customer to deliver a highly modular, polylithic software solution that provides a high degree of flexibility and adaptability? Yes, no doubt — indirectly. But would you ever ask your customer to validate a new class and verify that it complies with the Liskov Substitution Principle.
The Liskov what?!?
That is exactly my point. If you would not expect your customer to conduct user acceptance testing against a story (user, team, or otherwise), then it should never be a story on your backlog. Customers will not care how you write your code, so long as they get what they want, when they want it. Stories must solve the customers’ problems, not the problems of the team.
Related Posts
assistant Development Tip
Small Stories
Facilitate DevOps by starting with user stories that are small enough to complete within a few hours, or at worst, within a few days. While this often feels counter-intuitive, working with small stories will accelerate delivery while reducing WIP, promoting frequent feedback, facilitating early error detection, reducing variability in workflow, and increasing quality. Read More
assistant Development Tip
Working Software
Put working software in your users' hands as early and as often as possible while evolving your software through continuous delivery. Feature teams and component teams should often showcase software that is complete and potentially shippable. This will facilitate early and frequent feedback, provide true indication of progress, enable early release (when needed), and... Read More
assistant Development Tip
Single Actor
Write user stories for one specific actor to facilitate the development of a loosely-coupled, modular architecture. This will promote compliance with the Single Responsibility Principle to ensure that functions, classes, and components have a single reason to change. Writing stories that service a single actor will also help achieve Separation of Concerns. Avoid writing stories for... Read More
assistant Development Tip
You Aren't Gonna Need It
Design and implement solutions that are needed today; do not invest in capabilities or features that may never be needed. While this may require more effort tomorrow, time is more often wasted by investing in requirements that change or become irrelevant. Building for tomorrow will likely slow down delivery for today. Keep your codebase as small as possible. This will promote... Read More
assistant Development Tip
Separation of Concerns
Build flexible, highly adaptive software systems by separating all but those parts of a system that are closely related and require direct interaction. All other parts of the system should be designed and built independently, while having little to no knowledge of other parts of the system or the system as a whole. This can be achieved by encapsulating cohesive information and logic into... Read More
assistant Development Tip
Liskov Substitution Principle
Build classes in such a way that a derived class can always replace its base class without changing behavior or side effects of the base class. The derived class can do more than its base class, but must never do less. This principle governs inheritance, polymorphism, and subtyping. LSP violations may be discovered through degenerate functions, derived methods that do nothing but throw exceptions, or... Read More
