Steps to take to create the Product Backlog for starting our project with Scrum

Question

A small team (3 or 4) are working on a fairly big project that might take 1 year to complete.

We are basically re-designing an existing software (that had been developer over 5-6 years while being used without any direction). Currently we have a list of things we would like to have (features). We have about 25 of them.

How do we effectively turn these into a number of backlog tasks and also build our specs from here. Any resources or help would be appreciated as we are all fairly new to design process.

Answer 1

The ideal form for your backlog items are User Stories.

They are easily maintainable. Don't forget that the backlog is a tool to organize them (estimates + prioritization), not to document them.

I suggest you to have a look at User Stories Throughout the Agile Life Cycle

Answer 2

First thing to remember about Agile is that it's more a philosophy than a methodology. Do what works for you. You can start with something formalized like Scrum or whatever, but at some point you need to customize.

What we do is attempt to evaluate all the stories that we have. If there's something that's too complex or large for a single sprint (which for us is 2 weeks) then we split it up. We try to split it up into chunks that matter. For example, drawing text on a diagram display. Story 1 is to just get text up there. Story 2 is to be able to select and move it. Story 3 is to have it move when you move what it's attached to. Story 3 is to allow the user to change the font...etc...etc... We have something reasonably useful at the end of each sprint that could, should the business leaders so decide, actually release the product that way.

This bit takes a good while and you shouldn't assume that you'll get it perfect or even try to necessarily. You just want something reasonably agreed to that will show progress and velocity as your team progresses.

Answer 3

You have a project which has been developed 5-6 years and now you want to build a new project which will take only 1 year. There is obvious discrepancy leading to only single question: Do you have Product owner who understand current system, understand needs for a new system and is empowered by management to define priorities for features implemented during next year? If the answer is no then you have a big problem and until you solve it you don't have to continue. You need such person who will have responsibility and power to define the project based on business / user / customer real needs.

You have 25 features but what is size of your features? The most common description of the feature is user story. User story is not a documentation of the feature - it is "promise" of future discussion / communication which defines the content and constraints of the discussion. User stories should be small - no user story can span more then one iteration (sprint). If you have larger features you can call them Epics and Themes. Theme is whole area / business domain and it can be divided into multiple Epics. Epic is large set of features defining some main functionality and it can be divided into multiple user stories.

User stories, Epics and Themes defines product backlog but only User stories should be planned for an iteration. Once something is defined as Epic or Theme it means that it is too big and uncertain for a team to make a valid estimation and it must be divided before it can be planned. It's product owner's job to define user stories and to divide epics and themes.

It is very common (and valid) that not all features are known at the beginning and not all of them can be defined at the beginning of the project (if you try to do it you are going back to waterfall). Product backlog in agile is defined and modified continuously during whole project development. If you need a spec / scope of your project let's try to define themes and possibly the most important epics. This scope will not be fixed. As you build an application you can find that some theme / epic / user story is obsolete or your schedule will not allow you including it to a release. In the same time another more important theme / epic or simple user story can be added.