Chapter 6. Grooming and Planning

As the development process progresses, the requirements/user stories are groomed into functional input for the development teams. The priority of the user stories and the estimates of their size are important factors when the development team is considering their commitment to the work. This chapter presents a variety of strategies for grooming the stories. Once the grooming is complete, the sprint planning begins, incorporating the velocity of the team, the definition of “done,” the amount of technical debt, and more. Finally, we explore the theory of triple constraints (scope versus time versus resources) and how the management of these can affect the development process.

Backlogs vary in their depth, breadth, and quality. Jeff Sutherland (2011), one of the signers of the Agile Manifesto, pleads for technical excellence in the quality of the product backlog, citing it as one of the areas of improvement for Agile teams.

Mike Cohn provides sound guidance on how to improve backlog quality using the acronym DEEP, which stands for Detailed appropriately, Estimated, Emergent, and Prioritized (Cohn 2010, p. 253).

Detailed appropriately means that the highest-priority stories contain sufficient detail for the development teams to deliver them: Questions are answered, and the necessary clarifications are included in the story description. Acceptance criteria, as described in Chapter 5, are a component of the essential detail for the story.

Estimated means that the team understands the stories and believes there is adequate information to estimate the level of effort or amount of time required to deliver the story. We explore estimating thoroughly in this chapter.

Emergent refers to the backlog’s constant evolution: As new information is learned about the marketplace, a competitor, or a technological advancement, the backlog is modified, reprioritized, or clarified.

Prioritized means exactly that—the user stories are in priority order, with the highest-priority items that will deliver the most business value at the top of the backlog for immediate development. We also cover the prioritization process in this chapter.

Where the product backlog is housed will vary from company to company. Some firms, typically with smaller teams that are all colocated, may have a physical backlog with sticky notes hanging on the wall in priority order (see Figure 6.1). As collaboration between the business, product owner, and development team affects the priority, the sticky notes are simply rearranged.

Some companies, particularly those with virtual or remote team members, will opt to house their product backlog in a tool such as Jira Agile (see Figure 6.2), Rally, or numerous other online options.

Value must also be supported by a positive return on investment (ROI), so the cost to deliver a desired feature must be considered. If there is no way to recoup your investment because the cost of delivering the feature is so high, then the value deteriorates and the feature should be deprioritized. For example, data format for weather information in Iceland is not compatible with our application and would require a significant amount of code to convert it to a usable format. The cost of the data conversion compared with the revenue potential for adding Iceland data reveals that this would not be a wise undertaking and would cost far more than it is worth. Therefore, a user story requesting Iceland data should be removed from the backlog with the explanation for the decision.

Lastly, there is a consideration of the risks associated with the feature development: If this feature might jeopardize the stability of the application, then its value is diminished. You can see that value is not a simple equation and that many factors—revenue, cost, risk, and penalties—must be considered.

Because Lean emphasizes eliminating waste and delivering the most value in the least amount of time, mapping the value stream from the customer’s perspective can help with prioritization activities to ensure we are satisfying a meaningful customer need in a way that adds value to the organization.

• Must have: All features classified in this group must be implemented, and if they are not delivered, the system would simply not work.

• Should have: Features of this priority are important but can be omitted if time or resources constraints appear.

• Could have: These features enhance the system with greater functionality, but the timeliness of their delivery is not critical.

• Want to have: These features serve only a limited group of users and do not drive the same amount of business value as the preceding items.

Using Cayman Design as our example, we want to produce our weather-related calendars for purchase to create a new revenue stream. For this product, we have certain priorities with respect to the payment processing portion.

• Must have: Ability to accept MasterCard and Visa

• Should have: Add American Express and Discover

• Could have: Add ACH payments for transactions directly through banking institutions

• Want to have: Add gift cards

As you can see, if we cannot accept MasterCard and Visa, then our offering is not viable; therefore, that requirement is a “must have.” Adding American Express and Discover is important to our success, so they should be added as quickly as time allows; hence they fall into the “should have” category. Accepting ACH payments will broaden the appeal of our product but it does not have to be delivered early in the project, so that is a “could have.” Adding gift cards will serve only a limited audience, so that would fall into the “want to have” category.

The model assists with the prioritization process because it breaks down features into three categories. The first is basic needs, which are sometimes referred to as satisfiers/dissatisfiers. These are the features that must be there for the product to work, in the eyes of the customer: The functionality is expected, and if it is not included, it causes great dissatisfaction. After a consumer’s basic needs are met, then there are performance needs, which add necessary functionality to enhance the user experience. The final category, which results in true product differentiation, consists of features that delight or excite users, and they are an unexpected bonus from the consumer’s viewpoint. The challenge when it comes to prioritization is to focus on enough of the basic needs, performance needs, and delighters to deliver a compelling product to the marketplace. If you have a product with only delighters but no basic needs, then you might have something really innovative that does not work. Conversely, if you have something that satisfies every basic need but does not delight, then customers may not be compelled to buy it because it does not offer anything special or different from the competition.

Another aspect of the Kano model that is critical to understand is the evolution of the feature categorization: Over time, delighters will become performance needs, and performance needs will become basic needs. To illustrate this concept, think of the first iPad that you experienced. It had a number of features that delighted: The touchscreen with the swiping capabilities was awe inspiring when first encountered, but now if we see a tablet that is not a touchscreen, it is completely dissatisfying. The delighters have become basic needs as the competition has evolved and the technology has advanced. Therefore, companies must continue to prioritize delighter features if they want to remain innovative.

Ideal time is a useful metric because it is relatively easy for a developer to estimate, provided that the requirements/user stories are well defined and thorough.

There are a couple of other considerations on either side of the spectrum. First, some teams add a 0 (zero) to their Fibonacci sequence, but one might question why a story with zero points or no level of effort is even in the mix. Some teams use this as a placeholder to remind them of an activity that another team must complete; a dependency (Cohn 2005, p. 53). For example, this task requires no effort on the part of Scrum team A but needs to be delivered by Scrum team B before Scrum team A can complete its work; therefore, it sits in Scrum team A’s backlog with zero points.

Some teams add 200, 500, and/or infinity (∞). The reason for these additions is that people (typically management or stakeholders) are used to comparing things as though they relate, which is not always the case. For example, the team estimates an activity at 100 points because it is an epic and they do not have enough information to make a more precise assessment. As that feature is better understood and broken down, it is eventually delivered in five months. Some members of the management team might now equate a 100-point story with a five-month delivery cycle, which is not true at all. The next 100-point story—which is equally epic and lacking in information—may take twice as long to deliver, so there is no relative comparison. To eliminate the opportunity to compare, some teams have started using infinity to represent “not enough information.”

One additional thing to keep in mind is that unlike hours, which have a fixed and commonly understood definition, story points are more abstract and negotiable. One team may assign 3 points to a story where that same story on another team would have been a 2 or a 5. As long as everyone on the team agrees to the size of a story point, then all of the estimating will be coherent.

The easiest way for a team to get started using story points is through relative sizing; this involves identifying a task that everyone is familiar with and assigning a point value to it. Let’s say that adding a field to the database happens frequently, so everyone is aware of the effort and time required. The team assigns that activity as 5 story points, and then every subsequent story is compared to that one. Is this activity bigger or smaller than adding a field to the database? If it is bigger, then it could be an 8 or a 13; if it is smaller, it could be a 2 or a 3. Starting with something relative provides a benchmark for new teams. It is also worth noting that the testing activities should be included in the story point estimation. If an action is easy to develop but challenging to test, then it should receive a higher estimate because designing, coding, and testing are all part of completing a story.

In addition to an estimated size, we are looking to see if there is a discrepancy. If a user story is discussed and one team member throws a 2 but another throws a 13, then there is a difference that needs to be discussed. It does not mean that one person is right and the other is wrong; this actually identifies a lack of common understanding as it relates to the user story. Just like all of the other opportunities within Agile for collaboration and discussion, this discrepancy should be explored. Why did the developer who threw the 13 think that this task was so big? Is there a point of interconnection that the other developer (who threw the 2) was not thinking of? Did they just understand the request differently? Or has the low estimator done something like this before, so he or she is very confident in that assessment? Again, the value is in the dialogue, so everyone can come to a common understanding of the request and what it will take to fulfill it. The result could be that the team agrees on a 2 or a 13 or on a number in between. The point of the exercise is to facilitate collaboration and negotiation so the team is clear on the desired feature and confident in their ability to deliver.

If you have a distributed team so not all team members are in one location, there are tools such as http://www.planningpoker.com/ that allow you to have the same poker game over the Internet.

We discuss more about planning meetings later in the chapter.

The goal of the grooming session is to leave the meeting with good, solid user stories that are prioritized, discussed, well understood, negotiated, and agreed upon so that the next few action items (described next) can take place to ensure a successful sprint.

The product owner is responsible for leading the grooming session. Good product owners value the dialogue between the participants and recognize the benefits of the diverse backgrounds and perspectives of the group (Rubin 2012).

When a team first comes together, it is difficult to estimate their velocity because they have not yet experienced an iteration as a team. The first few iterations are usually more guesswork than precision, and that is fine because it provides the opportunity to inspect and adapt. Once the team is established and finds their rhythm, velocity is a great tool to use when establishing their commitment for future iterations.

Nevertheless, a few factors can disrupt velocity. If the team members are not dedicated to the team full-time, for example, it is hard to predict their availability to work on the next iteration; their other responsibilities could consume 20% or 50% or 80% of their available time, so it is difficult to count on their contributions. Similarly, if the team members change frequently, it is difficult for the team to find their rhythm—if Bill is part of the team and then removed and then put back on the team, it is hard for the other team members to depend on his deliverables.

Another negative impact on velocity is modifying the length of the sprint: If the team works on a two-week sprint, then a one-week sprint, then a two-week sprint again, it becomes difficult to gauge their capacity over a specified time period. Ideally, you want a team to work together for several iterations of consistent duration; then you will have the data you need to calculate the team’s velocity for planning purposes.

Personnel considerations for things such as vacation and training are yet another dynamic that will affect velocity. If a team will have two members on vacation for half of their iteration, then clearly they should not commit to the same level of work as if everyone were present. Although this might sound obvious, when a team experiences a dip in velocity, it tends to raise questions: Why was team A progressing at a velocity of 30 points per sprint for four iterations and then suddenly dropped to 20 points for the most recent sprint? Rather than raising alarms that something is amiss on the team, the best place to start is to simply look at team member availability.

Other elements that affect velocity could be external to the team, such as the stability of the infrastructure. If the development team is continually called upon to fix production problems, then they will have less time to spend writing new code. As we discussed in Chapter 2, “Organizational Culture Considerations with Agile,” if the executive team and/or stakeholders are not committed to the sacredness of the sprint and repeatedly introduce new changes, then calculating the team’s velocity can be very challenging.

There is no defined number of sprints that must be completed in order to calculate velocity; it is an ongoing, evolving measurement to be used as an input for the planning process.

Velocity should not be used as a management metric because it is based on story points, which are an arbitrary unit of measure defined by each individual team; teams with a higher velocity may not be more productive than others with lower velocity. In fact, management needs to be careful to avoid using velocity as an indicator of performance or productivity because it could lead to unhealthy behaviors on the team (Rubin 2012, p. 137). There are a few different ways to calculate velocity over time. Some teams simply average their totals for all of the sprints/iterations that they have worked on. Other teams, particularly those that are new to Scrum and are improving in their abilities, will use the concept of “yesterday’s weather,” therefore using only the last two to three sprints as indicators of their future capacity.

Extreme Programming also has the concept of velocity for planning purposes, but it allows for two types of planning: You can either set a date and determine how many stories can be implemented by that date, or define a specific scope and determine how long it will take to finish a defined set of stories. Either way, the team’s velocity is used to make the projections (Wells 1999).

Because Lean encompasses some of the manufacturing ideology, the developers are working with a pull scheduling system, where they “pull” in the right amount of work that can be completed in the time frame allowed. Once the team establishes their velocity, they will pull in only the amount of work that they can reasonably complete (Poppendieck and Poppendieck 2006, p. 70).

The same is true on development teams. Does your team include code reviews in your definition of done? Does your product owner think that the team is going to update the release notes before a sprint is considered completed? These are important conversations to have to ensure that everyone is on the same page. Every new team should dedicate time to discussing and agreeing on their definition of done, which may or may not include elements such as code that is checked in and integrated and has automated tests (Cohn 2010, p. 259). When the definition of done is clear and well understood, then we ensure that the conclusion of every sprint will meet everyone’s expectations.

Extreme Programming handles the definition of done slightly differently: When a task is completed, it is crossed off of the board. To ensure that done means done, in XP, only the customer (not the developer) can cross off a task (Beck and Fowler 2001, p. 81); from Chapter 4 you will remember that the customer in XP is equivalent to the product owner in Scrum.

There are many definitions of technical debt; in fact whole books have been written on this subject alone (see References and Further Reading for details), so we use a basic description here, for illustrative purposes. Technical debt was first discussed on the C2.com wiki page, and the definition created by Ward Cunningham is commonly used today: “Technical Debt includes those internal things that you choose not to do now, but which will impede future development if left undone. This includes deferred refactoring” (Cunningham 2012). Chapter 7, “Testing, Quality, and Integration,” provides much more information on refactoring.

There are two basic kinds of debt—unintended and intentional. Unintended technical debt is simply the consequences of the team’s learning curve. Perhaps they designed something poorly or did not test thoroughly enough, or the business was not 100% certain about the business requirements. No matter what the root cause, this type of debt is unintentional—no one meant to write bad code or be sloppy—and it happens as part of the continuous learning process that is essential to Agile.

Intentional technical debt is incurred as trade-offs are made in the development process. We may choose to incur technical debt for short-term, tactical reasons or long-term, strategic ones. Let’s consider some examples. Because our weather application for Cayman Design is going to be available with only information for the New York area in its first iteration, we are going to code the database lookups in a way that is quicker to deliver the initial release but will not be scalable once the data for the entire country is loaded. We decide that this is the best path, knowing that it will create technical debt, because it is the fastest way to release the initial version. It will allow us to research and learn more about the optimal database design once we better understand how users will interact with the application. Another example might be that Cayman Design is a cash-strapped start-up and can afford only certain hardware until we get revenue coming in, so we must code to those constraints. Again, we realize and accept that this creates technical debt that will have to be cleaned up once we are a thriving, profitable organization.

When we are ready to tackle technical debt, should it be included in the backlog of prioritized stories? Although there is some debate on this topic, most experts agree that it should. The technical teams may have to argue their case to the product owner to prioritize the efforts appropriately, and a good product owner should listen and understand the impact of allowing the debt to fester.

• Groomed and prioritized backlog

• Estimates for the highest-priority stories

• The velocity of the team

• Definition of done

• The schedule of the sprint—are there vacation days or a company holiday that will affect the amount of work we can commit to?

• Other inputs—are team members getting new monitors, is there an All-Hands meeting that everyone is required to attend?

1. Once we understand the user stories, the team will decide how many stories can be committed to during this sprint. This is the sprint goal.

2. The team then breaks the user stories down into individual tasks.

3. Each team member selects the tasks that he or she is willing to own and complete.

4. The team member then estimates—in hours—how long it will take to complete each task.

Important things are happening in this small list that need to be discussed in greater detail. With item #2, user stories are broken down into tasks. Some teams skip this step and a single developer is responsible for the entire user story delivery. More frequently, each story will contain several distinct pieces—for example, there is an update to the user interface, a new database field, an update required for the API to add the new field, and so on. Each of those individual tasks can be owned by different developers depending on their level of expertise. Furthermore, in item #3, team members select the tasks that they will own, which creates an opportunity to cross-train or develop new skills, as we have discussed in previous chapters. One developer, for example, may be the expert on inventory but another may be interested in learning inventory; the second developer could pick up inventory tasks during the Sprint planning meeting. Then when they get to step #4, the team might add some time to their estimates of how long it will take to complete the inventory tasks because the second developer is less experienced and will need more time.

Another important outcome of the Sprint planning meeting is that story points are converted to actual hours and the hours are attributed to the tasks, not the stories. The thought is that story points are appropriate for stories in backlog grooming and hours are appropriate for tasks in Sprint planning because the level of detail is increasing and therefore the confidence in estimating is greater and can be more precise. For the teams that estimate in hours to begin with, this step is still important, because the original estimates may need to be modified now that the team knows more and the developer who will be doing the work is known.

It is important to note the participants in the different parts of the planning game. “Because customers have the most information about value—they’re most qualified to say what is important—they prioritize. Because programmers have the most information about costs—they’re most qualified to say how long it will take to implement a story—they estimate. Neither group creates the plan unilaterally. Instead, both groups come together, each with their areas of expertise, and play the planning game” (Shore 2010).

Agile looks at the theory of triple constraints slightly differently. First, there is a school of thought that scope and quality are, in fact, two very different things: A team could deliver the prescribed scope at lesser quality, or it could maintain acceptable quality standards with a reduced scope. As Wells (1999) explains, “The base philosophy of release planning is that a project may be quantified by four variables; scope, resources, time, and quality. Scope is how much is to be done. Resources are how many people are available. Time is when the project or release will be done. And quality is how good the software will be and how well tested it will be. No one can control all [four] variables. When you change one, you inadvertently cause another to change in response.”

It is important to understand the concept of the triple constraints when engaged in planning and grooming, because one must grasp that changing one variable will impact other variables and appropriate adjustments will be needed.

Another way to look at this in an Agile environment is to suggest that resources and time are fixed. The team size is five to nine people, so that cannot change. The date is fixed by the duration of the sprint, in many cases two weeks. Therefore, scope must be flexible to be able to be designed, coded, and tested within the confines of the sprint. By managing the size and priority of the stories in the backlog, you are effectively managing the scope while the time and resources are fixed.

• The product backlog, which houses all of the requirements/user stories, should be DEEP—Detailed Appropriately, Estimated, Emergent, and Prioritized.

• Feature-driven development uses a technique called “plan by feature” to ensure that developers understand the feature categorization and priority.

• Prioritization by business value is common, and it is more than just proactive measures such as increased revenue or improved customer service. Sometimes priority is driven by reacting to the competition, evaluating the cost of an effort, and understanding the risk that a new feature might introduce to the technical environment.

• Value stream mapping is a useful exercise taken from the Lean principles, where an entire interaction is viewed through the eyes of the consumer to identify bottlenecks and inconsistencies.

• Using the DSDM method of prioritization called MoSCoW, we identify the Must haves, Should haves, Could haves, and Wants.

• The Kano model emphasizes that to be successful, products must fulfill basic needs and enhancement needs and delight end users. Over time, delighters can become basic needs, so ongoing innovation is important.

• Estimation can be done in t-shirt size, ideal time, hours, or story points, with story points being the most common in Agile. Estimations should always include testing.

• Most teams use the Fibonacci sequence for story points, which is a mathematical series where the first two numbers sum to the third: 1, 2, 3, 5, 8, 13, and so on. For most Agile teams, any story larger than 13 points is too big to fit in a single iteration.

• Planning poker is a game/tool used in Agile to estimate the size of efforts where team members play a card corresponding to their estimate. Differences are discussed and reconciled to ensure teams have a common understanding of the effort required to complete the story.

• Wide-band Delphi is a similar but much more formal and structured sizing exercise, in which estimates are submitted to a facilitator anonymously and discussed until reconciled.

• Product backlog grooming is a Scrum event where the team collaborates on the user stories. In this meeting, the product owner is a “pig” and clarifies the requirements.

• Other inputs to the product backlog grooming include the velocity of the team, the definition of “done,” and the incorporation of technical debt and bugs.

• Technical debt can be either intentional or unintended, and if not appropriately addressed, can jeopardize the long-term viability of the system.

• The Sprint planning meeting is another Scrum ceremony where the top user stories are committed to for the iteration, and the team breaks down stories into individual tasks.

• Tasks are selected by the team members, not assigned, which is a large shift from Waterfall practices and leads to higher developer engagement.

• Extreme Programming hosts a similar meeting called the planning game, where the “customer” sets the priority and the developers estimate the size of the effort.

• Many organizations must consider incorporating maintenance work on the platform and balancing it against the product development enhancements within an iteration.

• The triple constraint of time, resources, and scope is expanded in Agile to include quality, and teams must understand the trade-offs when adjustments are made to projects.

Kristin and Sondra: Backlog grooming—who should attend? How do you maximize the value of the meeting? Can it ever be fun?

Mike: Product backlog grooming is not yet an official Scrum meeting. It’s just something that many teams have discovered is a valuable thing that can lead to a more productive sprint planning meeting. As such, there’s no consensus on who attends. My view is that a subset of the team is adequate. Although I’m generally a big believer of whole-team involvement, that isn’t really practical for this meeting. Product backlog grooming usually happens two to three days before the end of a sprint. There is almost always someone on the team who is frantically busy two or three days before the end of a sprint. If we make that person attend another meeting, we could risk delivery of whatever product backlog item the person is working on.

Maximizing the value of a product backlog grooming meeting probably comes down to the same few things for any meeting: Keep it as short as possible, show up prepared, and encourage everyone to participate.

I have a hard time thinking of any meeting as truly fun, but I do think that when working with the right teammates, meetings can be viewed as welcome breaks from the more intense work of the team. Good teams can establish a rhythm where teams alternate from very intense mental work either alone or in pairs punctuated with occasional meetings. The meetings can have as much of a social tone as anything else and be a case for some joking around with teammates and just a bit of mental break before diving back into the more mentally intense solo or paired work.

Kristin and Sondra: What are the most common mistakes in a sprint planning meeting?

Mike: The most common mistake in sprint planning is misunderstanding the purpose of the meeting. Because one of the artifacts of sprint planning is a sprint backlog, many teams obsess over getting the sprint backlog perfect. These teams try to identify every last task and put a perfectly precise estimate on each task.

But that’s not the goal of sprint planning. The goal of sprint planning is to select the right set of product backlog items to work on during the sprint and to feel that each has been discussed enough that the team is prepared to work on it.

Focusing too much on the tasks and their estimates leads teams to spend too much time in sprint planning. The tasks and the estimates are necessary, but they are tools a team should use to decide which are the right set of product backlog items to select for a sprint.

Kristin and Sondra: Estimating is really hard. How can we get the best estimates of story size?

Mike: Estimating is definitely hard, but there are a few things teams can do that help.

First, try to keep most estimates—or at least the most important estimates—within about one order of magnitude. There are studies that have shown humans are pretty good across an order of magnitude but that we are bad beyond that.

Second, estimate in relative rather than absolute terms. Rather than saying, “this will take five days,” say “this (one story) will take about as long as that (story).” Then use velocity to determine how long each of those things will take. Not only is relative estimating more accurate, teams can do it more quickly. With relative estimating, the team does not need to think of all of the substeps, estimate each, and add them up. They only need to find something similar and use the same estimate.

Finally, rather than think of putting an estimate on a product backlog item, think of putting the product backlog item in the right bucket. I coach teams to do this by preidentifying a set of values they can assign as estimates. We’ll commonly use values like 1, 2, 3, 5, 8, and 13, which is, of course, the Fibonacci sequence. Each number represents a bucket of that size. When estimating a product backlog item, the goal is to put the item in the right bucket. If the team thinks something is a 10, it goes in the 13 bucket because it’s too big for the 8 bucket.

Kristin and Sondra: Should bugs, maintenance, or technical debt be part of the backlog?

Mike: They should definitely be part of the product backlog. The product backlog contains everything the product owner would like to do with the product. It the product owner wants those items addressed, they belong on the product backlog.

Beck, Kent. (2000). Extreme Programming explained. Boston: Addison-Wesley.

Beck, Kent, and Fowler, Martin. (2001). Planning Extreme Programming. Boston: Addison-Wesley.

Chandramouli, Subramanian, and Dutt, Saikat. (2012). PMI Agile Certified Practitioner—Excel with ease. Delhi: Pearson Education India.

Coad, Peter, De Luca, Jeff, and Lefebvre, Eric. (1999). Java modeling in color with UML: Enterprise components and process. Upper Saddle River, NJ: Prentice Hall.

Cockburn, Alistair. (2004). Crystal clear: A human-powered methodology for small teams. Boston: Addison-Wesley.

Cohn, Mike. (2005). Agile estimating and planning. Upper Saddle River, NJ: Prentice Hall.

Cohn, Mike. (2010). Succeeding with Agile: Software development using Scrum. Boston: Addison-Wesley.

Cunningham, Ward. (2012). Technical debt. http://c2.com/cgi/wiki?TechnicalDebt.

De Luca, Jeff. (2003). Getting flexible with planning. De Luca on FDD Newsletter, 1. http://www.featuredrivendevelopment.com/node/508.

DSDM. (2011). Dynamic Systems Development Method. http://dsdmofagilemethodology.wikidot.com.

Jones, Capers. (2007). Estimating software costs. New York: McGraw-Hill

McConnell, Steve. (2006). Software estimation: Demystifying the black art. Redmond, WA: Microsoft Press.

Mugridge, Rick, and Cunningham, Ward. (2005). Fit for developing software: Framework for integrated tests (Robert C. Martin Series). Upper Saddle River, NJ: Prentice Hall.

Nash, Adam. (2009). Guide to product planning: Three feature buckets.Blog entry, July 22. http://blog.adamnash.com/2009/07/22/guide-to-product-planning-three-feature-buckets.

Palmer, Stephen R., and Felsing, John M. (2002). A practical guide to feature-driven development. Upper Saddle River, NJ: Prentice Hall.

Pichler, Roman. (2010). Agile product management with Scrum: Creating products that customers love. Boston: Addison-Wesley.

Poppendieck, Mary, and Poppendieck, Tom. (2006). Implementing Lean software development: From concept to cash. Boston: Addison-Wesley.

Pressman, Roger. (2005). Software engineering—A practitioner’s approach (6th ed.). Boston, MA: McGraw-Hill.

Rubin, Kenneth. (2012). Essential Scrum: A practical guide to the most popular Agile process. Boston: Addison-Wesley.

Shore, James. (2010). The planning game. http://www.jamesshore.com/Agile-Book/the_planning_game.html.

Shore, James, and Warden, Shane. (2007). The art of Agile development. Sebastopol, CA: O’Reilly Media.

Stellman, Andrew, and Greene, Jennifer. (2005). Applied software project management. Sebastopol, CA: O’Reilly Media.

Sterling, Chris, and Barton, Brent. (2010). Managing software debt: Building for inevitable change. Boston: Addison-Wesley.

Sutherland, Jeff. (2011). Ten year Agile retrospective: How we can improve in the next ten years. http://msdn.microsoft.com/en-us/library/hh350860(v=vs.100).aspx.

Sutherland, Jeff, van Solingen, Rini, and Rustenberg, Eelco. (2012). The power of Scrum. Seattle, WA: CreateSpace Independent Publishing Platform.

Wells, Don. (1999). Release planning. http://www.extremeprogramming.org/rules/planninggame.html.

Wiegers, Karl. (2006). More about software requirements: Thorny issues and practical advice. Redmond, WA: Microsoft Press.

Wu, Liming. (1997). The comparison of the software cost estimating methods. http://www.compapp.dcu.ie/~renaat/ca421/LWu1.html.

2. What does DEEP stand for?

3. Should features provided by the competition influence prioritization?

4. Whose viewpoint is used in value stream mapping?

5. In the Kano model, do delighters sustain over time?

7. Why is the Fibonacci sequence preferred over regular numbering for estimating?

8. What happens during product backlog grooming?

9. What does velocity tell a team?

10. What is intentional technical debt?

12. In the XP planning game, during which phase is customer prioritization completed?

13. Describe at least two ways that teams can incorporate maintenance work into sprint planning.

a.

b.

14. In Agile, what constraint is split into two distinct considerations?

15. If you want to remove resources from a project and the scope is fixed, what needs to change on the project?

17. How do you handle discrepancies in planning poker?

18. With wide-band Delphi, how are the estimates gathered?

19. Who owns the estimates in XP?

20. Is the product owner a chicken or a pig in the Sprint planning meeting?