Product Requirements

Over the last few weeks, we've taken a look at several aspects of user story writing. As the primary means of kicking off conversations between product and engineering in most Agile environments, user story writing is a critical skill to develop. Let's review where we'

You've written your user stories, engineers have accepted them, development is in progress. Now what? More often than not, odds are you left off one of the most important parts of a user story - the acceptance criteria. Acceptance criteria tells you when a user story is ready

Over the past couple of weeks, we've looked at how to write good user stories, how to use themes to manage your backlog, and how to measure and predict the impact of user stories. Today, we'll take a high-level look at how to prioritize user stories.

On Tuesday, we looked at how to measure the impact of each user story, looking at both measuring the effectiveness of the mechanics of the feature and also the impact of the story on our overall product goals. Today, we'll look at how to predict the impact of

On Thursday, I wrote about how to use themes to stay focused on your product goals. But using themes is not enough. You also need to identify how you are going to predict and measure the impact of each user story. Let's return to our previous example and

One of the biggest challenges with writing requirements as user stories is that with time your backlog can become an overgrown mess of assorted stories that seem to have no rhyme or reason. When writing a PRD, it's easy to keep the whole product in mind. After all,

In April, I wrote User Stories Are Better Than PRDs. To date, it's been one of my most popular posts. It covers the basic format of user stories: As a user role, I'm able to do some functionality, for some explicit benefit. It looks at each