Starting your Scrum

The first step in Scrum is for the Product Owner to articulate the product vision. This takes the form of a prioritized list of what’s required, ranked in order of value to the customer and business, with the highest value items at the top of the list. This is called the Product
Backlog, and it exists (and evolves) over the lifetime of the project (figure 2). At any point, the
Product Backlog is the single, definitive view of “everything that could be done by the team ever, in order of priority”. Only a single Product Backlog exists; this means the Product Owner is required to make prioritization decisions across the entire spectrum of work that could be done.
The Product Backlog will include a variety of items, such as features (“enable all users to place book in shopping cart”), development requirements (“rework the transaction processing module to make it scalable”), exploratory work (“investigate solutions for speeding up credit card validation”), and known bugs (“diagnose and fix the order processing script errors”).
Many people like to articulate the requirements in terms of “user stories”: concise, clear descriptions of the functionality in terms of its value to the end user of the product.
The Product Backlog is continuously updated by the Product Owner to reflect changes in the needs of the customer, new ideas or insights, moves by the competition, technical hurdles that appear, and so forth. The team provides the Product Owner with rough estimations of the relative effort required for each item on the Product Backlog, and this helps the Product
Owner make prioritization decisions (since some items become less of a priority when the
Product Owner learns that major effort will be required to deliver them). Since these estimations are relative, they can be measured in “points” rather than real-world units of effort such as person-weeks; over time, though, as the team gathers data on its velocity (how many of these relative “points” it is able to complete in a period of time), it is able to use this data in projecting release dates and other longer-term planning.
The items in the Product Backlog can vary significantly in size; however, the larger ones will often be broken into smaller pieces during the Sprint Planning Meeting, and the smaller ones may be consolidated. One of the myths about Scrum is that it prevents you from writing detailed specifications; in reality, it’s up to the Product Owner and Team to decide just how much detail is required, and this may vary from one Product Backlog item to the next. The general advice is to state what’s important in the least amount of space necessary – in other words, one doesn’t have to describe every possible detail of an item, one should just make clear what is necessary for it to be considered completed. The further down the Product
Backlog one goes, the larger and less detailed the items will be; as they get closer to being worked on, additional detail gets filled in by the Product Owner.

Key fields in product backlogs (SCRUM)

Our stories include the following fields:
(*)ID – a unique identification, just an auto-incremented number.
This is to avoid losing track of stories when we rename them.
(*)Name – a short, descriptive name of the story. For example “See
your own transaction history”. Clear enough so that developers
and the product owner understand approximately what we are
talking about, and clear enough to distinguish it from other
stories. Normally 2 – 10 words.
(*)Importance – the product owner’s importance rating for this
story. For example 10. Or 150. High = more important.
o I tend to avoid the term “priority” since priority 1 is
typically considered the “highest” priority, which gets
ugly if you later on decide that something else is even
more important. What priority rating should that get?
Priority 0? Priority -1?
(*)Initial estimate – the team’s initial assessment of how much
work is needed to implement this story compared to other stories.
The unit is story points and usually corresponds roughly to “ideal
man-days”.
o Ask the team “if you can take the optimal number of
people for this story (not too few and not too many,
typically 2), and lock yourselves into a room with lots of
food and work completely undisturbed, after how many
days will you come out with a finished, demonstratable,
tested, releasable implementation?”. If the answer is
“with 3 guys locked into a room it will take
approximately 4 days” then the initial estimate is 12
story points.
o The important thing is not to get the absolute estimates
correct (i.e. that a 2-point story should take 2 days), the
important thing is to get the relative estimates correct
(i.e. that a 2-point story should require about half as
much work as a 4-point story).
(*)How to demo – a high-level description of how this story will be
demonstrated at the sprint demo. This is essentially a simple test
spec. “Do this, then do that, then this should happen”.
o If you practice TDD (test-driven development) this
description can be used as pseudo-code for your
acceptance test code.
(*)Notes – any other info, clarifications, references to other sources
of info, etc. Normally very brief.