In Scrum all the work revolves around the Product Backlog. This is the list showing all of the items the customer wants to have. This is the list the Scrum Team takes it tasks from. In this article I will explain how to increase the value of the Product Backlog and therefore the Scrum process. Please add your thoughts.
First of all: logically the customer will want everything that’s listed on the Product Backlog. He should, because he has given the input for the list in the first place. Unfortunately time and money are usually not infinite. This applies to all organizations whether they use Scrum, Waterfall or any other software development method. If you just build everything the customer wants you run the risk of not getting things finished in time or at all.
In my organization time is the most important constraint. We work in two week sprints, but releases happen only every three months. If not enough Backlog items have reached status 'done' to release a certain functionality it will be pushed back another three months.
The root of the problem is that the customer’s wishes include various sorts of bells and whistles. We are talking about things that reduce manual steps, make the functionality easier to work with or even just make it look prettier. Things that promise to increase value, but extend beyond the basic functionality. Often it takes a lot of hours to realize all of this and it can mean that the functionality takes months to reach production status.
That’s why in Scrum we strive to work on the most important bits of functionality first. If there’s time and budget left in the release you can implement the less essential elements, but you can at least release the core functionality.
This means that you have a Product Backlog where the items are prioritized properly. This often involves splitting Backlog items into smaller items. So you must know and describe them in more detail. But we are told that in Scrum you should avoid describing your Backlog items in too much detail. First of all we can’t expect the customer to know every detail beforehand. Secondly getting too much detail too early will probably make it old news by the time you will need it. How to tackle this problem?
What we should try is to strip every backlog item down to its barest essential. Everything that can be omitted without breaking the functionality should be seen as a separate Backlog item. So instead of trying to describe every possible aspect and ask the customer whether he needs it and how bad he needs it you peel off as many aspects as you and the customer can think of. The description of these secondary Backlog items can be general. Further detail will come when the Scrum Team is ready to pick it up. Note: redirecting things into separate Backlog items does not automatically mean that they will not be built! It just means that we’re not building them right away.
When you have determined the most essential and the less essential Backlog items it’s much easier to prioritize. The goal should be to release the core functionality as soon as possible. First of all the customer will start getting value from the functionality and secondly he will get used to it. There is a good chance that some of the less essential items that were planned for a next release will be scrapped as the customer is content with current functionality. That will give the Scrum team time to work on the next project.
Let’s look at an example. Suppose an organization wants to build a 'Customer order information portal'. There is no existing customer or product portal. The organization only has a regular website. It's not difficult to identify the big items:
1. There should be login functionality. This way the system knows what customer to display the order information for.
2. There should be pages displaying the order information.
3. There should be a connection between the front office (HTML files) and the back office application (database).
4. There should be reporting functionality for the customer so he can print or send information to himself via email.
5. There should be logging functionality documenting who logged in and when, to help debugging and for security reasons.
These items are very general. There is hardly any core functionality discernible. Items 4 and 5 can be thought of as less essential, but more importantly all of the items could contain all sorts of bells and whistles. So we should try to peel them to the core.
Let's look at the first item: login functionality. Which aspects can you think of?
· The customer needs to be able to log in, so you should build ‘something’ that contains usernames and passwords and ‘something’ that can verify what the customer has entered on the website against this module.
· Functionality for the customer to choose his own password via the portal.
· Functionality for the customer to retrieve or reset a lost password.
· Functionality to have multiple accounts per customer (for instance for management, financial department etc.).
· Functionality for the customer to login automatically based on .Net Passport, Gmail or something along that line.
Really, with the first item you can go live. All the other items are nice, but not having them doesn’t make the customer portal impossible. Therefore the other items can be put on the Product Backlog with a lower priority. And it’s not necessary to have the precise details of these items yet. You do the same with the other general items.
Now the big challenge will be convincing the customer. The customer can be very concerned about the features that are put lower on the priority list. In the old system (other waterfall) it usually meant that it would be scrapped later on. It’s the job of the Product Owner to keep the focus on what is being built now and not what is being built later. The customer has to understand that it’s more valuable to have basic functionality soon than to have complete functionality at once at some unknown point in the future. Usually after having seen how it works the customer is more comfortable with the idea.
So summarizing in this article I argue that it's good for the process to get the Product Backlog right. You should at least have the most basic version of the functionality at the top of the list. Everything that goes beyond it should be lower in priority. This ensures that the Scrum Team is always doing what's most important to get the functionality valuable enough to release.
