Scrum Advice: Creating the First Product Backlog

Scrum methodology is gaining recognition as an effective way to manage development projects. So, I thought it might be a good time to talk about some of the main elements of the Scrum framework for the PMs and managers out there. A good place to start is with the “Product Backlog” – which for the novice could be equated loosely to the functional requirements list.

The Scrum product backlog delineates the functions required to provide the outcome desired by the product owner. According to Ken Schwaber in “Agile Software Development with Scrum”, the backlog includes a list of all the functionality, features and technology needed to complete a development project.

Although the product backlog sounds like the requirements document used in traditional waterfall software development methodology, it is not. Don McGreal, VP of Training at Improving Enterprises, LLC and my Scrum trainer, describes what happened in his experience to requirements documents under traditional software development methodologies, “Never did we ever build what we first came up with in the requirements phase.” In the project close out to assess how well the system met the specified requirements, we didn’t. We would ask, ‘what went wrong’ and there was a blame game or a lot of excuses about unplanned for events. The managers would then decide that the solution for next time was to make the requirements more detailed – more time should be spent upfront on creating the complete requirements.

However, spending more time trying to create a perfect requirements document at the beginning of a project is doomed to failure. Admit it, says Don (and I agree completely), before anything is built, “users, customers, even experienced practitioners cannot specify everything that should be built.” Instead of spending weeks, months or even years creating a comprehensive requirements document in the beginning, Scrum practices acknowledge that requirements will change during development and recommends creating only an initial list of things the product or system needs to do.

The first product backlog is based on a vision, business analysis and even marketing promises. The initial list gets the team started working on functionality quickly. During the development, the requirements listed in the prioritized product backlog — which is updated before each sprint — will evolve into what can and should be done using empirical data gained by writing and testing code.

Creating the product backlog is the responsibility of the product owner. He or she may create a high level description of the end product’s capability as a vision statement or concept of operations. The product owner may get inspiration from user stories of what they do currently and what would make their tasks easier. There is a real art to collecting useful user stories. I suggest:

  • Having many conversations with potential users. Carry a set of index cards to the meeting. On each card there is a sentence that begins, “As a _________________, I need to do _______________.” This simple format device gives the product owner a concise statement of a requirement.
  • Holding a brainstorming session with a small group of users and facilitating discussion about what they need to do their jobs. Having several people talking together creates an environment where one person’s comment will stimulate the thinking of others.
  • Working with customers, create a scenario that walks a user through an entire series of steps needed to achieve a successful interaction with the system. Each step in the scenario can be an item in the initial product backlog. Add scenarios for many types of user’s needs.
  • Meeting with the development team to review the vision and initial product backlog. Add items to the backlog to accommodate identified needs for further research or infrastructure requirements needed to get started.

From these activities, the product manager builds the prioritized initial product backlog. The product manager gives the team a presentation of the product vision and the product backlog list. The team and the Scrum master meet to plan the first sprint, which may achieve completing the highest priority task or may break that high priority task into several sprint tasks.

Remember that Scrum’s power comes from iteratively evaluating product backlog priorities and tasks. As Project Managers we have been doing this for years in order to make sure the project goals are still valid.  Over time new tasks are added to the backlog. Each sprint planning meeting accepts the highest priority tasks that can be completed during the next sprint.  At the end of a sprint, the team delivers the demonstrable functionality of the backlog task, revisits how the deliverable fits within the product vision and identifies the next priority tasks from the product backlog.

The above ideas are methods I have found successful to create the initial product backlog. If you have techniques you find particularly useful to begin the Scrum backlog generation, please share.

Why C-Level Managers May Fear Scrum and Agile

Implementing Scrum techniques as a project methodology (or really a framework) represents a major culture change in a traditional organization. In the beginning, the change agent, Scrum Master or Scrum champion may encounter resistance from C-Level managers because they hear the words used to describe Scrum through a different filter than developers. This difference in perception becomes greater as the size of the organization and the distance from project execution increase.

Scrum Words

What C-Level Manager May Think

Self-directed team No management or controls
Daily Scrum meetings No work will get done if the team is constantly having meetings
Product and Sprint backlog priorities determine the next set of tasks There is no over-all plan, design or Gantt schedule – will they ever be done?
Scrum team members do not have job descriptions How can individual performance be evaluated (and raises distributed) if I do not know what each individual is expected to do and how well they do it?
The Scrum team decides how much work can be completed during a sprint We bill the customer based on completion of Contract Line Item Numbers accepted — how can I predict income?
Only the product owner can change the backlog Does that mean I cannot go to “good ‘ol Paul” and get him to add a little-bitty new feature over the weekend?

In my experience there are techniques to lessen C-Level concerns about Scrum. For example, I recommend scheduling an orientation meeting for senior managers with several objectives in mind:

  • Identify the problems and challenges that drive the decision to try Scrum
  • Use numbers — how many projects deliver on time, how many complaints from customers, how often requirements change after the original contract is signed.
  • Tie problems and challenges to the cost of maintaining and upgrading
  • Demystify Scrum terms by mapping them to more commonly used concepts such as (“Scrum as Project Management” Kevin Thompson from CPrime):
  • Schedule = Sprint (or Release)
  • Scope = Sprint Backlog
  • Work Breakdown Structure = Task Breakdown
  • Productivity = Velocity
  • Estimate to Complete = Burndown Chart
  • Explain the Scrum process and framework. Show how Scrum is designed to remove some of the conditions that lead to problems in traditional or waterfall developments.
  • Reassure them about the transparency of Scrum projects and the rapidity by which problems are identified or changes accommodated.
  • Have a game plan to implement Scrum that reduces perceived risks, such as starting with a small project or prototype.

Once permission to “try it” is given, setup conditions to maximize success including:

  • Select the team, product owner and Scrum master. Send the product owner and team to Scrum classes – Like Professional Scrum Master (PSM) training. This training needs to be more than reading a book or attending a one-hour seminar — although these are a good place to start. Follow up the introduction with a formal class — usually about two days of instruction from a Scrum Trainer.
  • Provide senior management with a brief report about the training. Your goals are to provide information, reassurance and keep the interest alive.
  • Ensure that business analysts, marketing or systems people work with the product owner in the beginning to establish the vision and the stories.
  • Engage a coach to assist in the first few weeks or months who is an experienced PSM or scrum practitioner.
  • When the team understands the vision and the product backlog, allow them to self-organize including setting up work space, planning sprints and conducting daily Scrums.
  • Use the Scrum master to facilitate interaction, ensure Scrum procedures are followed and remove barriers to performance.

Give them closure

This is not a task that needs to be done every time – just during the Scrum demystification and selling phase. Either in a report or preferably a short meeting:

      • Review the reasons Scrum was assessed as an approved framework and methodology.
      • Review the Scrum terminology and the framework (events, artifacts, and roles).
      • Describe the process used. Emphasize business value of the process and the deliverables.
      • Do a demo (we call this a Sprint Review).
      • (Here’s a key item) Provide two or three, articulate testimonials from the team and the product owner / customer. What did they like. How did they feel working under a Scrum framework?
      • Have a plan that shows a progressive increase in number of Scrum projects, gaining Scrum master status for knowledgeable professionals, and ongoing staff training.
      • Ask for questions and concerns: then address those immediately, either during the meeting or within 24 hours.

For those of you who have instituted Scrum in a tradition-based organization, your observations and suggestions are appreciated.

(On a personal note – several of you had asked me to report on my certification and I passed my Professional Scrum Master test this week!)

_____________________________________________________________

Resource:

“How not to do Scrum”; New York City Scrum User’s Group

http://www.qualytic.com/sitebuildercontent/sitebuilderfiles/how_not_to_do_scrum_v4.7.1.pdf

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

ProjectManagement.com

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

How to Manage a Camel - Project Management Blog

Project Management Recruitment, Careers and News from Arras People

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management

beyondcenter

Pushing the Edges Out ...

projectxpert

Just another WordPress.com site