Locked lesson.

Upgrade

About this lesson

Project requirements management in an Agile/Scrum project is conducted using Story Cards and Backlogs.  The list of requirements is variable and is not finalized until the end of the project.

Exercise files

Download this lesson’s related exercise files.

Requirements Management.docx
62 KB Requirements Management - Solution.docx
61.8 KB

Quick reference

Requirements Management

Project requirements management in an Agile/Scrum project is conducted using Story Cards and Backlogs. The list of requirements is variable and is not finalized until the end of the project.

When to Use Requirements Management

Agile/Scrum projects often have variable and varying scope. Because of this, the maintenance of the Product Backlog and Story Cards must be continuous throughout the life of the project.

Instructions

  • A fundamental difference between traditional projects and Agile/Scrum projects is that the scope in Agile/Scrum projects is intentionally varying.
  • The requirements in an Agile/Scrum project are documented with Story Cards and organized through the use of the Product Backlog. Neither of those techniques is used with traditional project management.
  • Traditional project scope and requirements management techniques such as the Scope Statement and the Work Breakdown Structure (WBS) are not appropriate for Agile/Scrum projects. 
    • These techniques are used in the early Initiating and Planning stages of a project and then baselined.  From that point on, they cannot be changed without undergoing formal change procedures.  However the Agile/Scrum Product Backlog is regularly changing.
    • The Agile/Scrum methodology requires that the Stories in the Product Backlog be prioritized. There is no provision for prioritizing elements of the Scope Statement of WBS. These techniques treat all requirements as equal.
  • The Product Owner will collect the desired requirements from stakeholders in order to create Story Cards. Often there will be conflicting requirements or conflicting Demo Criteria from different Stakeholders. The Product Owner must reconcile these differences. 
    • Find a compromise or hybrid Story that all stakeholders agree with.
    • Select one Story and reject the other(s). Be prepared to discuss the decision with stakeholders.
  • The Product Owner must guard against a directed solution approach in the Story Card and the Demo Criteria. Stakeholders will often try to “design the solution” and expect the project team to clean up the mess they create. In the Agile/Scum process, the team determines how best to meet the requirement, not the stakeholder.
  • Stakeholders will often request changes to Stories or the addition of new Stories during the Agile/Scrum project. The Product Owner can determine the best way to accommodate these changes. Normally they are allowed for any Story that is not being currently worked in a Sprint.
  • The primary project characteristics that will determine the actual project scope, and therefore the list of project requirements is the amount of time in the project and the number of people on the Scrum Team. Those two factors will determine how many of the Story Cards can be completed.   
  • The potential requirements and scope boundary for a Sprint is the Sprint Backlog.
  • The potential requirements and scope boundary for the total project is the Product Backlog.

 

Hints and Tips

  • On large projects, requirements management is the most challenging aspect of the Product Owner role. The Product Owner will need to regularly review the project goal or vision and let this act as a guide when writing and including Story Cards in the Product Backlog.
  • This is the time when internal politics will impact the project. Different stakeholders will attempt to influence the Product Owner to ensure their Stories are accepted onto the Product Backlog and that they are prioritized to occur early in the project.
  • The Product Owner should let the stakeholders with low priority requirements know that they may not get what they want from the project. A little foreshadowing can help to soften the blow if their Stories are not completed in the project.
  • When a stakeholder has a very aggressive requirement – to the point that it seems unrealistic, I will often create two story cards. The first one is the requirement being performed at a basic or standard level. The second is the requirement at the aggressive level. I make sure the standard level requirement is a high priority, but the aggressive level is lower. That way I can assure the stakeholder that the requirement will at least be met at the basic level and that we will strive to get the high level.
Login to download
  • 00:04 Hi, this is Ray Sheen.
  • 00:05 Let's talk about requirements management on Agile Scrum projects.
  • 00:08 This is one of the sharpest areas of differences, between traditional and
  • 00:12 Agile Scrum.
  • 00:14 You are probably familiar with the definition of a project.
  • 00:17 That it is a temporary endeavor undertaken to create a unique product, service,
  • 00:21 or result.
  • 00:22 That product, service, or
  • 00:23 result is normally defined by a set of requirements that the project must manage.
  • 00:29 The Agile Scrum method does not use the traditional tools for
  • 00:32 managing requirements such a scope statement or a work breakdown structure.
  • 00:36 These techniques tend to create a fixed set of requirements or scope, and
  • 00:39 they do not normally prioritize between the requirements.
  • 00:43 These aspects become issues when using the Agile Scrum methodology.
  • 00:47 Agile Scrum has a high level goal or vision, but
  • 00:50 it does not rely on detailed specifications.
  • 00:53 Rather, it relies on the product owner deciding periodically
  • 00:56 what should be in and what should be out of the project scope
  • 00:59 in order to achieve the vision within the project constraints.
  • 01:03 The desired requirements are documented on the story cards, and
  • 01:06 the story card includes the demo criteria which helps to clarify exactly what
  • 01:10 the requirement means.
  • 01:12 The stakeholders will often want to change or add stories to the product backlog.
  • 01:17 The product owner can decide how best to manage the process.
  • 01:20 There are no changes allowed to stories that are in the sprint backlog
  • 01:24 of an existing sprint.
  • 01:25 But any other story in the product backlog could be changed if the product owner
  • 01:29 thinks it is in the best interest of the project.
  • 01:31 And will improve the ability to achieve the project goal.
  • 01:35 Now incidentally, the use of story cards and
  • 01:37 demo criteria is just a format difference
  • 01:40 on how requirements are documented as compared to traditional projects.
  • 01:44 The big difference is the determination of the scope boundaries,
  • 01:47 which means deciding which stories will actually get done.
  • 01:50 Agile Scrum projects are different because the scope boundary is fluid.
  • 01:55 Requirements are being added or removed on a regular basis.
  • 01:58 In addition, the demo criteria, which is such a fundamental part of definition of
  • 02:02 a requirement, is often changed in the middle of a project.
  • 02:06 What we have is a big wish list that is constantly changing.
  • 02:10 The Product Owner decides which of the wishes are most important Important and
  • 02:13 prioritizes the list.
  • 02:15 But how many are actually done will be based upon the number of sprints and
  • 02:19 the number of scrum team members who participate on each sprint.
  • 02:23 Once that has been determined, the product owner can use the velocity measure
  • 02:27 to back into a probable set of stories from the product backlog list.
  • 02:31 Even then, the final list won't be set until the final sprint is complete.
  • 02:36 So the scope boundaries for a sprint still vary, until the sprint is complete.
  • 02:41 You could say that the sprint scope is determined at the sprint demonstration
  • 02:45 Once all the work is done.
  • 02:47 And the full project scope is set after the last sprint
  • 02:50 in the Agile/Scrum project.
  • 02:52 If the business wants the project to accomplish more
  • 02:55 they need to add more sprints.
  • 02:58 Which brings us to the point in deciding what's goes in to the wish list.
  • 03:02 Better known as the product back log.
  • 03:04 As the product owner gathers potential requirements, he or
  • 03:07 she will inevitably find some conflict.
  • 03:10 Different stakeholders want different incompatible project results.
  • 03:14 Or they may want the same thing in general, but
  • 03:16 the specifics as documented in the demo criteria are inconsistent.
  • 03:20 When faced with this situation, the product owner must find a solution.
  • 03:24 One approach is to negotiate with the different stakeholders to find a hybrid or
  • 03:28 compromise requirement that all can agree upon.
  • 03:31 If the product owner can't find a compromise, then he or
  • 03:34 she must pick which requirements will be included and which will not.
  • 03:39 Even when there isn't any conflict,
  • 03:41 a stakeholder might have an unreasonable expectation.
  • 03:44 The product owner will need to negotiate both the story and the demo criteria.
  • 03:48 A technique that I have used is to write two story cards.
  • 03:52 One is with the basic level performance, and
  • 03:55 I give that story a very high priority.
  • 03:57 Then the second story is to improve that performance into the difficult or
  • 04:01 nearly unreasonable range.
  • 04:03 I give that a lower priority.
  • 04:05 That way I can assure the stakeholder that they will at least get some of what they
  • 04:09 want, but maybe not everything.
  • 04:11 Also, be careful that the stakeholder does not try to force a solution through
  • 04:15 the demo criteria.
  • 04:17 They should state a business impact or customer impact.
  • 04:20 And let the scrum team decide how best to create the solution.
  • 04:24 The negotiation of difficult and
  • 04:26 vague requirements is a challenging part of the product owner's job.
  • 04:30 Add to that the original product backlog, is often far longer
  • 04:34 than what could be completed within the planned number of sprints.
  • 04:37 As the product owner starts to prioritize the product backlog, they will soon get
  • 04:41 a sense of which stories will likely get accomplished and which ones will not.
  • 04:46 The product owner will need to set appropriate expectations with
  • 04:48 the stakeholders, and office politics often begin to factor in at that time.
  • 04:53 No one wants to go to a senior manager, and
  • 04:56 tell them they can't get what they want done on a project.
  • 04:59 In my opinion, managing the priority of the stories on the backlog, and
  • 05:03 therefore managing the scope of what the project will contain,
  • 05:07 is the most difficult part of the Product Owner's role.
  • 05:12 Agile Scrum project requirements are managed very differently than traditional
  • 05:16 projects.
  • 05:17 They're fluid and changing, often not finalized until the project is complete.
  • 05:23 And an agile Scrum project scope vary's, not schedule or cost.

Lesson notes are only available for subscribers.

PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.

Gift this course