LinkedIn principal author Doug Winnie describes how to take product features and create user stories with your team. With a user story, you define who the feature is for, what they will do with it and define the estimated time required to build it. Using these stories, you can define the work for your sprint based on the available capacity of your team.
- When you prioritize features, we need to carefully consider the amount of time and effort that goes into building them. It's easy to overlook invisible features that aren't exposed to the users but that your team needs to have in place to build the product. Here's some ways you can help define the requirements for your product and create narratives for your features; called stories. These stories are the basis of what you create in your product. The first thing you need to do, is look at how much time you have to build.
Capacity is the time you have to do the work you need to do. Let's say we've defined a three week build phase for your product and five people will contribute to this phase. Assuming each person is available to put in 30 hours of work each week, and assuming there will be meetings and interruptions, that'll take up some of their work time. You estimate that you have 450 hours of build time, or, capacity. A story is a narrative that you write as a product manager, which identifies the work to be done, and who will benefit from it.
For our example, we are building an app for schools which can notify teachers, students, and parents about test scores and progress throughout the school year. We can create a user story like this one. "As a teacher, I need to add a test, homework assignment, or other graded activity to the calendar for my class." This story defines who the feature is for; the teacher, and what they need to do. When you write this, you discuss it with your team and one of them asks about pop quizzes.
A teacher knows they're going to have a quiz, but they don't want the students to know, so you create another user story. As a teacher, I need to be able to change the visibility of a graded activity on the calendar to hide it from students. As your team continues, they define more stories based on the conversation and exploration of the feature. But something comes up that could be an issue. You need to have a way for the engineers to create fake events, to be able to test the app.
This would be a feature that would never be used by any users but it is critical to people to test the app quickly. So, you create an internal story. "As an engineer, I need to be able create a fake set of graded activities to test the app." When you have all these stories created, you need to score them. Ask your build team how much capacity they need to make the feature. It might have to be a rough guess at the beginning because they probably won't have mockups or designs to go from yet.
To score them, you need to define how much capacity will be required to design and build them. Start with general degrees of size; like small, medium, and large. Small could be a day or two days, medium could be a week, and large could be two weeks. Then assign an amount of time to each item to create a complete user story. Now you can see how much work you have to do, and compare that to the amount of capacity you have. If you have too little capacity, you need to decide which of the stories will be punted to the next sprint, or, you need to revise the feature.
One option for revising a feature, is to break it up into smaller features. That'll allow you to get some of it done in the current sprint, and enhance it in a future one. Another option is to increase capacity by adding more team members to the project, or by cutting meetings from the schedule to free up a few more hours each week. In the end, you have a sprint plan. You have taken features and broken them down into requirements and stories that are weighted for time and effort, and can fit within your team's capacity.
- Types of products and industries
- Leading through influence
- Understanding your team
- Using an agile or waterfall development cycle
- Managing your product life cycle
- Researching your market, customers, and ideas
- Planning the product
- Building the product
- Releasing the product
- Refining the product
- Understanding when it's time to retire the product