Jason Isbell Always Delivers
Deliver Working Products
If you do one thing with your Scrum above all else: deliver working products.
If you are running a development team, that is what you are paid to do. So do it often, do it the best you can, do it in a repeatable way, and, most importantly, do it for a real customer who will judge your work and hold you accountable.
Great, another agile philosopher! Just what the world needs. Fair enough - let me provide some specifics on how you can upgrade your Scrum to make it more effective.
Here are three tips on improving your development in delivering working products.
Tip #1: Timebox, Don't Point, any Spike Tasks
A Timebox is a start and end date for a task. Therefore, the best way to approach a spike is to assign a beginning and end date. According to the Agile Dictionary, a spike is:
A task aimed at answering a question or gathering information, rather than at producing shippable product.
There it is: You are not delivering anything with a spike; you are gathering information. It isn't resolving a story - it isn't burning down a set of story points towards a product objective. It is gathering information so that you can complete a story.
Timebox your spike according to the story at hand.
Schedule time with the customer to understand why they need the story completed
Gather statistics from a working system to understand the scope of your story
Write up a Wiki page describing the problem.
Discuss your learnings with colleagues and customers
Tip #2: Specify the Story in a Consistent Form
When writing a story for a Scrum ticket, use the following form:
My Story As a <customer>, I would like to <use the component>, so that I can <achieve my goal> Acceptance Criteria After executing <the component> I will be able to <a specific action demonstrating the goal>
In addition, here is an excellent article on how to write stories better: It's time to start writing helpful User Stories!
When writing the acceptance criteria, use specific process examples or codified lists to formalize how to validate the functionality supporting the story.
Don't be afraid to go back and refine the stories during development.
Tip #3: Eat Your Own Dogfood
There is no such thing as perfect communication between people. The more the developer understands the customer, the better job they will be able to do. Too often, developers think their job stops at writing code. They expect a product owner to hand them the requirements, and they will dutifully type it out and release a product that works for the customer. I've never seen this work in practice.
If you are building a small product for a larger team, use your product internally on your team. See how your application functions in the real world and continually improve the user experience. The development team should fully support all their code in development and not ask operations for help. If it is too much work for the team to manage in development, they must go back and do a better job.