Have no doubt in your mind that there’s uncertainty involved in your project. You can’t possibly know exactly what it will take to build the right product for your customers so early in its life. You cannot gaze wistfully into a crystal ball and predict the future.

The “backlog” or “product backlog” is where your requirements live. Agile favors the writing of short, pithy statements that capture the essence of a “requirement.” The backlog is simply a long list of entries, each entry defining a single, discrete “requirement” as a user story. And from now on, we’ll be using the word user story, and not “requirement.” You’re probably asking “why?” That’s a good question. For what seems like forever, stating the features or facets needed in a software project by a customer has always been referred to as a requirement. That word has an interpretation that has no value in Agile. The Oxford dictionary defines it as:

A thing that is needed or wanted. Or, A thing that is compulsory; a necessary condition.

And unfortunately, if we set out defining what our solution should be, stating that things are “compulsory,” we will end up in trouble. It’s too easy to say that all these user stories are compulsory. If we take that view, we run the risk of running over schedule and over budget in the attempt to deliver all of a given scope. It’s not a problem to say that, for this product these stories are needed for the solution to be viable, we just want to avoid the interpretation of that particular word.

·         Always write stories from the perspective of a persona. A persona represents a user or stakeholder of the solution. It’s a good idea to develop these persona before you start a backlog.

·         At this stage, only write short, simple statements that basically suggest a reminder to have a deeper conversation about the user story when the time is right.

·         Real people think in terms of tasks that they need to get done to achieve a goal. Write your stories from the persona perspective and in terms of what they need to get done.

·         You don’t need to write the full backlog—just write as much as you can imagine your customers will need for your product to be viable.

·         You’ll discover later on through the life of the product that user stories will change, become more or less important, or can be deleted completely. Releasing often, getting feedback, and assessing what’s a priority will inform this behavior.

·         Don’t write stories in isolation. Engage your team, stakeholders, even your customers. Stories can be updated at any time in the life of a project but should avoid being changed once development work has started on them.

·         Some of your stories may be considered “epics.” These are large stories that cover a lot, and will be broken down closer to the time of delivery into smaller stories.

·         Consider using the INVEST model, a checklist for validating the quality of a good user story.

·         Anybody can add a story to the backlog. It should be placed at the bottom, or in a specially created “parking lot.” This added story serves as a prompt to discuss with the team and the business. If the business and team support it, it can then be estimated and prioritized

·         You may also consider those parts of the system that are most risky. If you have a user story or feature that is complex, new, or technically unknown, prioritize these to the top of your backlog. This way, you won’t be attempting to deliver the challenging and critical parts of your product just weeks before your first release.

Once you have a backlog that fulfills your needs, you can estimate the stories in it, rank them in order of priority, and build a release plan.