Your Project Requirements and Backlog Should Align
Sometimes the project requirements makes one appearance – at the beginning of the project. Your product backlog and user stories should be a breakdown of your project requirements. Your project requirements should be reviewed almost as much as your product backlog. Teams, priorities, and goals change in the course of a project. Your project requirements should be the foundation, not the product backlog.
Use a Product Roadmap as A Guide
Think of your backlog as your requirements to build a bridge. You can’t build a bridge if you haven’t planned what to do once you reach the other side. Your product backlog should be based on your approved product roadmap. If you have a backlog, but no product road map than you just have a task list.
Always Be Grooming
Sometimes items get into your backlog that doesn’t belong there. Maybe a stakeholder brought up a stakeholder in a meeting and it made its way to the backlog. Refining and prioritizing your backlog will keep it fresh and adjust to business needs.
Recap Backlog with Stakeholders
Because Agile and Scrum are always changing its easy for verbal conversations to be forgotten over time. The last thing you want if to spend 30 hours building a feature the client doesn’t remember asking for. Constantly review a high-level backlog with your stakeholders. In the recap focus on the business reason of “why”, focus less on the “how”.
Write Better User Stories
Most user stories suck. That’s because the person writing the user stories doesn’t understand the business well. Instead of writing user stories in a vacuum ask for a “User Story Session”. Invite the stakeholder and write or rewrite a few user stories from the backlog. This activity should be done in person with a whiteboard.
Less Meetings More Collaboration Sessions
True collaboration is in person. This is not always possible because teams are not located in the same building, state or country, but whenever possible have collaborated. Collaboration and meetings are two different things. The word “meeting” sometime drums up a negative meaning to it. Collaboration Sessions should be fun, interactive, fruitful and have a purpose or goal in mind.
Prepare for Product Backlog Meetings
Don’t prepare for your backlog meeting 10 minutes before the backlog meeting. Instead, print out your backlog and take 10 minutes out of your day marking it up with questions, suggestions, and ideas. One the day of your backlog meeting categorize your questions, suggestion, and ideas into bullet points. You’ll look organized and prepared.
Organize Your Backlog by Groups of Features
Your backlog should have a purpose and releases should bring you closer to solving your customers business challenges. “Picking the low hanging fruit” and “stating with the easier stories” is not necessarily the best way to clear a backlog. If we are building a car, putting in seats is a lot easier than putting in an engine, but are you going to do with a car without an engine.
Wireframe Whenever Possible
I’m a big fan of visuals and wireframes. They help everyone understand the “what”. Without visuals, it’s like giving directions in the dark. It’s possible but requires way more energy. Wireframes and visuals are a tangible representation of what the stakeholder wants. The wireframe can be on the back of a napkin. I prefer to start with a piece of paper and when I have everything drawn out switch to a wireframing tool. The extra time in the being will save you time in the end.
What are some of the challenges you have with your backlog? Feel free to vent in the comments section.