Category: product backlog
Introduction
Leading on from last week where I described that their are two main parts to user stories, the user (or persona or role) and the story (a short description of the intended functionality), this weeks blog is intended to focus on specific details on how to write good stories.
The three C's
Most of you are already aware of the 3 C's i believe originally conceived by Ron Jefferies - Card, Conversation and Confirmation.
Card
The card is important in that User Stories are meant to be written on Cards.
Bookmark/Search this post with:
Over the course of the past 5 years, I have often been asked about the role the Product Owner plays in an Agile company. More recently in a rather controversial
blog post by Adam Bullied he raised the question – Is there such a thing as an Agile Product Manager?
From my experience, there is. And this role in Scrum is defined as the Product Owner. The Product Owner from my experience differs from that of the traditional Product Manager role in many ways. Additionally, the role the Agile PM plays may vary depending on the environment and situation at hand, but for certain there are key activities the Agile PM must perform.
The Product owner (or Agile PM) shoulders all the responsibility for Project success and is ultimately responsible to the Team, stakeholders and to the company. With so much at stake it's easy to get bogged down or revert back to old ways and the whole team suffers as a result. In order for Scrum to work the Product owner has to focus his time on activities that matter. (read more...)
Bookmark/Search this post with:
Last week, I wrote down a new idea about how to determine business value using a variation of planning poker. At the same time, I tried out the method in a real project. How did Business Value Poker survive its first encounter with the real world?
Previously, the two product managers had come up with a list of functions. The dilemma was that Product Manager #1, the manufacturer of the complete system, valued new hardware sales generated by the software. P-M #2, a user of the system, valued operational savings. At the first attempt to prioritize, each manager was given 1000 points to distribute among the functions. The business value was the sum of each party’s vote. This produced a value but no consensus.
Bookmark/Search this post with:
Excel is one of the most popular tools for managing the backlogs of the Scrum process. There is a number of templates available and here is a screencast on using one of the advanced ones. This template was created by Petri Heiramo from Digia and includes facilities for managing both product and sprint backlogs. You can download this template on the page with the collection of Scrum templates and examples.
You might also like to have a look at the video tutorials on the simple product backlog template and simple sprint backlog template.
Bookmark/Search this post with:
Any project plan is a mixture of what the product owner wants and what the team can actually deliver. The product owner naturally wants more than the team can deliver, so s/he has to prioritize in order to get something useful in the desired timeframe.
Once you have a prioritized product backlog, you have the prerequisites for calling the first Sprint Planning Meeting. How do you convert an unordered list of features into a prioritized product backlog which you can give the team to implement? What should you do first?
I'm not sure that there is a correct answer to this question. It will depend on your product, your company and your situation. Let's take a look at some widely used strategies for prioritizing the product backlog
- Minimum Marketable Feature Set - the first pass to narrow the list of stories
- Business Value First - Focus on High Value Functions
- Bang For the Buck - Go for easy wins
- Technical Risk First - Do the hard things first
- Defer Risk - Do the hard things later (or never)
- Vote - Ask your users
Bookmark/Search this post with:
Once you know who you are building the product for, the next step is to create a list of features which will excite your customers and get them to use and buy one of your products. Which functions should you put into the system, and why? The user story workshop creates the initial product backlog.
This workshop is similar to the last workshop where you identified the users and buyers of your systems. This workshop needs the same people, except that the importance of the development team rises as you get closer to implementation. It is also desirable to have some real users represented. The workshop structure structure is simple:
- Review the format of User Stories and the Kano Model.
- For each Role,
- Identify the main goals
- Identify the functions which that person wants the system to perform to achieve those goals
- Decide on next steps: Homework or Implementation
Bookmark/Search this post with:
In the previous parts of this series (1, 2, 3, 4), I went into a lot of the initial issues of how we ran our project and some of the things we did wrong. For Part 5, I'm going to focus on the 5 big mistakes we made in the project before I move onto another phase of the series.
For some background, the project was to integrate an off-the-shelf (but highly customizable) billing system to replace an aging custom Oracle forms app. This was our company's first foray into Scrum and Agile as well as the first Agile experience for most of the development team. After we sailed past our second management-imposed deadline I started thinking about how we could correct our process for this project and the next ones we do, which led me to write it all down in this series. Keep reading for the Top 5 mistakes we made (in no particular order). Where possible I also give some detail about how we've worked on correcting our process. I hope this list helps you avoid these mistakes and make your own all-new ones. :)
Bookmark/Search this post with:
When defining a product, it’s easy to write down list of features and call it the product backlog. It’s much harder to build a product which so deeply and profoundly meets the needs of its users that they just have to buy it. An agile team can use a three workshop process to create the Scrum product backlog. Workshop 1: Identify the users. Workshop 2: Figure out what they want. Workshop 3: define the feature mix which will get you to a product that the customers want as quickly as possible. Let’s start with Workshop 1, the Users.
Bookmark/Search this post with:
In this tutorial I demonstrate how you can manage your Scrum Product Backlog in a very simple Excel sheet based on a
popular free template. Watch this screencast if you want to get started with Scrum. You will see how to get started, how to detail, inject and remove requirements, how to build burndown and velocity charts.
You can download the somewhat lower quality version of the tutorial
from Google Video.
See also
Bookmark/Search this post with:
One of the mandatory artifacts of the Scrum process is a Product Backlog. In its simplest form it is just a flat list of things to do, quite often even without the complexity estimates. Its power comes from the strict order of elements. Customer can call many requirements equally mandatory or must-have, but in the list there is no way to position two items equally high. As a result a team is able to see the clear focus and sense the current expected direction of the project. Product backlog is not static. It changes over time: coarse grained items from the bottom are divided into smaller stories as team comes closer to them, some items are removed and some are added basing on the increased understanding of the area, technology and the market. Still, at any given point of time well maintained product backlog is the primary tool for communicating the current best understanding of the project direction.
Multiple backlogs for a team
Several times I've seen the situation, when there is no single product backlog for a team, but there are several "area backlogs" from which the top part of a real product backlog is dynamically assembled before or even during the sprint planning. Naturally it happens more often in the situations, when one team has to develop several projects simultaneously or many teams do many projects.
Bookmark/Search this post with:
RSS feed
Subscribe on Kindle