Create Your Successful Agile Project

What are the Stages of Group Development?

1)forming, 2)storming, 3) norming, 4) performing

What are some ways to overcome the team consists of narrow experts trap?

1. Make sure your managers and reward system recognize flow efficiency, not resource efficiency 2. Ask the team to limit its work in progress, so that the team has to work together to finish features. 3. If you find it useful, consider lunch-and-learns. At a lunch meeting, one person at a time presents his or her area of deep expertise. 4. Consider pairing or mobbing to avoid reinforcing expertise. (See ​Work as a Whole Team to Create the Product​, for details on pairing and mobbing.)

How Should You Manage the 'Done' Column of Your Board?

1. The story meets the story-acceptance criteria. Consider adding acceptance criteria that discuss the larger environment for the story. 2. The story meets the team's agreements for technical excellence. 3. The product owner has accepted the story. If the story meets all these criteria, the story is really done.

What are some ways to create smaller Agile Teams?

1) Make the stories smaller so the team can be smaller. 2) Organize by feature or feature set. Aim for a feature team size of no more than six. If your feature set is too large for one team, consider organizing as a program around smaller feature sets. 3) If you have already organized by feature and the team is still larger than nine, check for team skills and capabilities. 4) break into several other teams and organize as a program? Sometimes when teams become large, it's time for each team to take a feature set (or two) and focus on those features. 5) If you still need a large team, consider measuring the team's throughput and see if the team waits for people outside the team or for people on the team.

How do You Define What Done Means for a Story as a Working Agreement?

1. All the code is checked in. 2. There are automated unit tests. 3. There are automated system tests at the API level. 4. All the automated tests are checked in. 5. All the tests pass. 5. The documentation for the feature is complete. 6. There has been some sort of pairing or other eyes on the code and automated tests to prevent shortcuts. Your team doesn't have to like these. It may want something different. I find it helpful to specify what "done" means as a working agreement so no one takes shortcuts. If people think they need to take a shortcut, they can discuss the problem that requires them to take a shortcut.

What are some ways to overcome the component team trap?

1. Ask the person you are missing to join your team full-time for several weeks. While that person works with your team, pair or mob on everything that person touches. 2. Explain to your management that you are missing a person with specific expertise. Your team doesn't have all the roles it needs. Maybe you can hire someone to join your team. 3. It's possible you don't have enough people because your managers are stuck in resource-efficiency thinking. (See the discussion in ​Managers Move from Resource-Efficiency to Flow-Efficiency Thinking​). Create a kanban board showing cycle time.

How Can You Give Management an Estimate of When All the Features Will be Done?

1. Ask the team to take all the details they know about the features in the roadmap. 2. Use whatever relative sizing approach you prefer. 3. Walk through the roadmap, estimating as you proceed. In addition, count the larger features. The larger the features, the more uncertainty you have in your estimate. 4. Add up your relative estimate (either points or cycle time). Add up the large features so you understand your confidence level.

How do you overcome the trap of developers and testers working in successive or staggered iterations?

1. Create and use a kanban board to see where the work is waiting for people or specific skills/capabilities. Now you can see who you need. 2. Measure the WIP to see how much work is waiting for which kinds of people or teams. Maybe that will encourage cross-functional team organization. 3. If you have functional teams, see the suggestion in ​Ask Teams to Organize Themselves​.

What are the two ways to Measure the Time Something Takes?

1. Cycle time The duration of time from when you put a card in the first in-progress column until when you mark the card as "done." Cycle time measures the time the team works on the story. 2. Lead time The duration of time from when a card goes onto the backlog until you release the feature to the customer. Lead time is the entire time from backlog to customer use. If you have a staging area before you can move your product to production, your lead time is at least the team time plus that time.

How do You Use Cycle Time for Estimation?

1. Decide on a time period for your measurement. I recommend you consider two to four weeks for your initial measurement period. That time might provide you enough information for your average cycle time. 2. As the team completes stories in this period, count the number of stories and measure how long each story took. You will have something like the following table.

What is the formula for Getting a Total Project Estimate?

1. Feature Sets 2. #Stories 3. Relative Estimate for Stories 4. Total Story Estimate 5. Confidence Level. - High, Medium, or Low

Describe a Cumulative Flow Chart?

1. Has the title of "Cumulative Flow: Number of Iterations" 2. The Y Axis is used for number of features (can be in 5 point increments) 3. The X axis is the Iterations used for this chart 4. Bars across graph represent type of work completed

What is the Agenda for a backlog planning meeting?

1. Prepare stories: The product owner prepares stories, preferably on cards that the team can see and handle. 2. Ask for new information: Ask the team about new ideas and issues that arose during the most recent time the team worked. This might be a good time to look at Table 11, ​Possible Improvement Parking Lot​, to see what to address in this backlog. Prepare cards for discussion. 3. Explain each story: The product owner picks up a card and explains it. Ask if anyone has questions about that card. It's possible that the team wants to discuss acceptance criteria or other stories the team thinks depend on that card. 4. Estimate the work: Once the team understands all the cards, estimate the work if the team uses iterations. 5. Rank the work: The product owner ranks the cards. (See Chapter 7, ​Rank the Work​, for ranking possibilities.) 6. Create the backlog: Add the ranked cards to the Ready column.

What are the Columns that Should be Used on a Kanban Board?

1. Ready 2. Discuss Story 3. Develop and Unit Test 4. Dev-Done 5. System Test 6. Done An "Urgent" que can be added by placing a line under the last story. This que can be used for production support work as well.

What are the two interpersonal skills needed for an agile team member?

1. The ability to receive and 2. provide feedback and coaching.

What are some Tips for Creating Small Stories?

1. Write the story on a 3x5 index card. You might have a tool that you're supposed to use to keep the requirements in. While you build your agile mindset and learn how to work as an agile team, use index cards. 2. On the front of the card, write down the story. 3. On the back of the card, write down the acceptance criteria. If your story and the acceptance criteria do not fit on one index card, the story is too big. Remember, stories are a promise for a conversation. The card does not have to have absolutely everything on it.

What does MVE Mean?

A Minimum Viable Experiment provides feedback for the team and the product owner. Sometimes we want to see something even smaller than a useful feature or feature set. That's an MVE. With an MVE, the product owner might think it's worth considering a feature set. But the product owner wants more data. That's why you create an MVE, something even smaller.

What is a Burnup Chart?

A burnup is a way to see what we have accomplished and what's remaining. I can learn more from a burnup than I can from a burndown. It contains: 1. Title of "Story Points Done" 2. Story points on the Y Axis 3. Days on the X axis 4. A line showing story points done

What is a Cumulative Flow Chart?

A cumulative flow chart shows how much work is in which state.

What is a Retrospective Meeting?

A retrospective is a look back at the team's actions and output so the team can learn what to do next.

What is Planning Poker and it's Process?

A technique used for relative sizing involving Fibonacci cards. Every person has a deck of cards with the sizes on the cards. If you use Fibonacci, every person would have eight cards, one each with 1, 2, 3, 5, 8, 13, 20, and 40. When the team estimates, someone, often the product owner, holds up a story and asks, "What's your estimate for this story?" Each person takes his or her card showing the relative estimate of each story. Planning poker is a Wideband Delphi estimation technique. It surfaces concerns and issues about a story so the team can resolve those issues or concerns, or know that the story might be troublesome. Planning poker is especially useful when team members disagree on the story's relative size. Teams decide what to do: go with a larger estimate or a smaller one—or break the story down into smaller chunks of value. If you have stories of size 1, planning poker is easy. You ask, "Does anyone think this is larger than a 1?" If so, the team has other choices: spike the story to timebox the work to one day to understand what else to do, or break up this story, which is really a feature set, into other stories.

What is a Theme?

A theme is a related group of stories. I call this a "feature set." You can deliver any of the related stories and realize value.

How do you know if your team is not working at a sustainable pace trap?

The team pushes to complete work just before a demo. The team wants a break between one chunk of work and the next. (In iteration-based agile approaches, teams want days or a week between iterations. In flow, the team members want a break between the work they complete and the next item on the board.) The team is working overtime all the time.

What is Acceptance Driven Development?

Acceptance test-driven development (ATDD) helps us create tests by thinking of the acceptance tests for the product.

How can You Make the Lack of Testers Visible?

Add an insufficient number or type of testers to your impediment board, as discussed in ​Visualize Problems with a Board​. Measure the cycle time, as discussed in ​Visualize Your Project's Delays​. Consider creating a table.

What is a typical User Story Format?

As a (particular kind of user), I want (some sort of action) to (provide me some achievement, value, or result).

What are Some Options if The Product Owner wants Detailed Estimates for all of It?

As a leader, have a conversation with the product owner and ask that person what she or he needs. Is the product owner under pressure to provide a detailed or specific delivery date for that entire feature set? If so, ask if the team can work on only that feature set until it's complete. Consider asking the team to swarm or mob on the first several features in the feature set so the team can learn as it proceeds. Measure the cycle time for each feature as the team proceeds. It's possible the later stories will take less time, but I have not always seen that. Remind the people pressuring the team for the large estimate that the larger the thing the team estimates and the farther out that work is, the less accurate the estimate will be. Ask what these people want. They might want delivery as fast as possible. In that case, work with the product owner to make the stories as small as possible, and ask the product owner to rank all the stories in this feature set higher than any other story. Create smaller deliverables, and demo them to the people who want the estimate for "all" of it. This shows the team and the person who wants the estimate how the team is proceeding.

How do you create a teams social contract?

Ask the team to flesh out its social values. 1. Ask everyone to meet for about 30 minutes. 2. Provide everyone with index cards and a large, dark marker. The team members will need to see each other's cards after writing them. 3. Ask each person to fill in this sentence: "I don't like it when someone/people...." Each person might write down anywhere from two to five of these sentences. 4. Divide the team into pairs. 5. In pairs, select one card. Work with your partner to write down a statement that counters the negative statement. For example, if you said, "I don't like it when some people tell me what to do," you might write a statement that says, "I like it when people discuss our technical approach as a team." Continue until each pair addresses all its cards. 6. Ask the pairs to read each "I like it" card out loud. As the team members read the cards, capture what they say on a flip chart to post in the team area. (Note: the facilitator does not read the "I like it" statements. The team members read them.) Ask the team to develop working agreements * Core hours—Does the team need to commit to core hours so everyone knows when members are available? * What "done" means—Does the team know what "done" means for a story? See the discussion in Chapter 11, ​Know What "Done" Means​. * How the team treats meeting times—What will the team do if people are late to meetings or don't attend at all? * What the team automates and when—It's not possible to automate all testing. On the other hand, it is possible to automate much of it. What does this team need to automate and when? * How the team responds to urgent requests—If the team needs to respond to production support requests, it needs to know what those parameters are. So does the rest of the organization.

How do you overcome the trap where distant managers are needed to overcome problems?

Ask these people to take a chance and allow the team to experiment with its process. Ask these people to empower you as the person who can facilitate the team's problem-solving process. Build your influencing and upward-coaching skills so you can work with these people over time to help them understand what agile approaches buy the team, them, and the organization.

What is Behavior Driven Development?

Behavior-driven development (BDD) is for specification by example, where given a certain context, when the user behaves in a certain way, then we can expect certain results.

What does Continuous Integration Mean?

Continuous integration means the developers (and testers) work on some small chunk of value, check that value in the version-control system, make a build, check that build, and, as long as everything works, they're done with that piece. When I think of continuous integration, I think of people checking in at least twice a day. I check in my work every hour or two. I recommend a smaller time frame rather than a larger one.

What does Swarming Mean?

The team works together on one story, but each person contributes based on his or her expertise. The platform developer works on the platform, the middleware developer works on the middle ware, the UI developer creates the UI. In addition, the tester develops tests. When each person is done with "their" part, that person offers his or her assistance as a pair to whomever is still working.

What is Cost of Delay in Story Ranking?

Cost of delay is the cost you incur from not releasing the work when you want to, and the implications of that delay on future revenue.

What is the peer-to-peer model of feedback?

Create an opening to deliver feedback. Describe the behavior or result in a way that the person can hear. State the impact using "I" language. Make a request for continued or changed behavior.

Why is Cycle Time Used for More Accurate Estimates?

Cycle time helps a team see how large its stories really are. Cycle time provides a team a rough rule of thumb for quickly estimating a large number of stories. Cycle time helps people see whether they tend to be optimistic or pessimistic estimators.

How do people become trustworthy?

Deliver what they promise to deliver Are consistent in their actions and reactions Make integrity a cornerstone of their work Are willing to discuss, influence, and negotiate Trust in themselves and their colleagues

What is an epic?

Epic A compound story that's not easy to tease apart. I find that epics often contain feature sets.

What are some responsibilities of an Agile Project Manager?

Facilitate the team's process. New-to-agile teams don't have the agile mindset and culture baked into their DNA. Who will learn more about how they can make agile work for them? Who will schedule the demo and the retrospective and make sure the two meetings occur? Remove or enable removal of impediments the team members can't remove. Many impediments are at the organization level. The team isn't going to tackle them. The team "delegates" the impediment to the project manager. Assist the team in measuring the team's velocity, cycle time, and any other measurements. This might be as simple as creating the space for the team to measure as they walk the board. Assist the product owner in writing stories for the next iteration. New product owners may not understand how to write small-enough stories for iterations. Facilitate the team's workshopping of the project vision. Facilitate the team's workshopping of the release criteria. Facilitate the team's working agreements, including the team's definition of "done." In addition, the team may need help in identifying and managing the team's risks. This can be many different things: Managing sponsor expectations. Too many senior managers think agile is a way to get "more, faster, cheaper" without realizing the team needs to learn—to learn how the product needs to work and to learn how to work as an agile team. Managing the project portfolio so the team has no context switching and is cross-functional and stable. Obtaining more funding if necessary. Making sure the long-lead-time items show up on time. This is especially helpful for projects with hardware or mechanical parts.

What is test-driven development?

Test-driven development (TDD) is when a developer writes a test that fails (red), creates just enough code to make it pass (green), and, when it's time to add to that code, refactors to clean any messes.

What are some charts to understand what the team completed and how much more remains?

Feature or story burnups to see feature progress. Feature charts to show what's done, what's added, and remaining features. Iteration contents to see what the team did, not just planned. Cumulative flow to see the WIP. Cycle time to see how long things take for this team. Defect escapes and bounce-back to understand how defects might affect the team in the future.

How Do You Define Acceptance Criteria for Each Story?

For acceptance criteria, I like the Given-When-Then approach from behavior-driven development: (Given) some context (When) some action is carried out (Then) you should see some set of observable consequences This approach creates scenarios for a story. You might even use the number of scenarios as a guideline for how large the story is. For me, a guideline is four scenarios. Once I see more than four scenarios, I worry that the story isn't small enough. (You might prefer a different number than my four.)

How do You Estimate Support Work?

For the next three iterations, measure the amount of support work the team does. Track the cycle time for the support work, regardless of what kind of a board you use. At the end of three iterations, see if the cycle time clusters around some average or mean. You might have two different means: the relatively easy support items and the much more difficult items. Now, leave room in the iteration for the number and type of support items you see from your history.

How do you Calculate the Number of Communication Paths?

Here is the calculation where N is the number of people on the team: Communication Paths = N*(N-1)/2.

What is the best practice for Product Road maps?

I run my business on an six-month big-picture roadmap and a one-month detailed roadmap. I update these roadmaps on a two-week rolling wave.

What are Some Things that can be Done if your team's cycle time increases, or if the fault feedback ratio becomes too high?

Identify the root cause(s) of the last six to ten defects. With any luck, they will share root causes. Here are some possibilities I've seen: fixing one defect uncovered more; cascading defects, where one defect causes several more; and the code is so complex that finishing anything is akin to climbing Mt. Everest. If the team understands the root cause(s), see if there is a handful of defects—which, when the team fixes them, will help it proceed faster. Sometimes the team needs to fix only a few things before it can make progress. Ask the team if it's collaborating and refactoring as it proceeds. Maybe it needs a practice radar chart to see if its practices lead to clean code.

In a Burndown Chart what does it Mean if Your actual line does not Meet the Ideal Line?

If it's above the line than you are "late.". I am emphasizing the word "late" here, because a team might not be late. It may have misestimated, or maybe someone was out sick for a couple of days, or someone got pulled into another project and is not working on the team's work. All of these problems are causes of "lateness." The burndown increases the idea of lateness.

What is an approach to Managing the Time People Spend in Meetings?

If the team uses iterations, consider a standup during the day. I like just before lunch. Other people select 9 or 9:30 a.m. Avoid first thing in the morning because people's commute time can vary every day. If the team swarms or mobs, the team might not need a standup. Consider timeboxing the backlog planning meeting to one hour for a two-week timebox. If the team can't get through everything in that meeting, consider retrospecting on what the product owner and the team bring to that meeting. It's possible the team needs to workshop the stories with the product owner and limit what the product owner brings to a planning meeting. Consider timeboxing any backlog-refinement work to one hour to prepare for the next set of backlog items.

What is the Process for Swarming?

In swarming, the team members work alone or maybe in pairs, according to their expertise and desire. They often start off the work with a short standup where people will say, "Here's what I will do." The swarming team discusses the story. Then the team members work as they choose (solo, pairs, triads) in a short timebox of one hour to work on their own. After that timebox, the team returns to check in with each other and see how the work is going for everyone. They might need to resolve issues in the code or the tests, so they decide what to do next. They then repeat the work and check in until the team finishes the work. The team has a cadence: work for an hour, check in with each other, scatter to work for an hour, check in, repeat until the item is done. If one person is done before the others, that person offers his or her services—possibly as a reviewer—to the rest of the team.

How Can a Team Achieve a Continuous Flow of Running, Tested Features?

Integrate often to see progress Keep the code and tests clean Work together to maintain throughput and focus Test at all levels so the team has support for frequent change

What is a Risk/Problem/Obstacle/Board

It is used to track impediments, risks, and other obstacles from the work. The columns used are: 1. Concern with / Date Added 2. Ready 3. In Progress 4. Waiting for External Decision 5. Done

What is ROTI?

It stands for Return on Time Invested (ROTI). It uses a five point scale a five-point scale similar to ask people to report how much value they received for the time they invested in the meeting. 0 = No benefit for the time invested 1 = A little better than zero. Some benefit but not commensurate with time invested. 2 = Value received equal to time invested 3 = A little better than even return 4 = High benefit. Value received greater than time invested. Post the ratings on a flip chart, and poll the group. Create a histogram that shows the results, as in the next figure. Then ask for information about what made the meeting worthwhile or not worthwhile. Ask the people who rated the meeting 2 or above what specifically they received for investing their time in the meeting. Ask people who voted 1 or 0 what they wanted but didn't receive for their investment. Ask what to keep, drop, and add for the next similar meeting. If a majority of the participants rate the meeting an even return for their time invested, a 2, the meeting is valuable. If a majority of the participants rate the meeting below 2, ask more questions. Was there a match between the people and the purpose of the meeting? Was the meeting run well enough? Was there something else that prevented people from gaining enough value from the meeting? Agile approaches do require more meetings than people might expect initially. Make those meetings valuable.

How do you overcome the trap of team membership not being stable?

Keep stable teams together.

How do you overcome the Trap where Everyone Takes Their Own Story?

Move to a kanban board and create WIP limits. This will help everyone see where the work is and if the team has bottlenecks. Ask the team to ​Swarm on the Work​, or ​Mob on the Work​, on every single feature. When people work together, they will finish the features faster. At a minimum, ask the team members to pair on every single story.

How to use the team's current velocity to feed that information forward to your next estimate?

Measure velocity for several iterations. Teams new to agile approaches often need six or seven iterations to discover their true capacity, their velocity. Does your team have an upper and lower bound? If your team measures in story points, it may discover that it can do 37 points in one iteration, 54 points in the next, and 24 in the third. That team's velocity is not stable. It might need to count feature story points separately from defect points, separately from changes. See ​Iteration Contents Show What the Team Completed​. Once the team's velocity settles down to +/- 10% in either features or story points, the team can check its current estimate against what it "typically" can do. In addition, if the team needs to estimate past the next iteration, it can use its average velocity to create a gross estimate.

What are the different types of meetings Agile Teams can have?

Meetings about the work and the work process: retrospectives, review of work in progress, demonstrations, and work-planning meetings Problem-solving meetings to address problems and risks teams discover that they want to manage as they review the work in progress Learning meetings so the team members can learn together and with other colleagues around the organization

What does MVP Mean?

Minimum Viable Product has enough functionality for the customer to use, even if it's not the full functionality.

Is Multi-tasking good or Bad?

Multitasking slows all throughput. It doesn't matter if a person multitasks or if a team multitasks. The more work any one person attempts to do at the "same time," the lower the throughput. To create great estimates, stop any multitasking.

Who Creates the Product Road Map?

Product managers (often with product owners) plan the product roadmap: what the product people want when.

How Often Should You Complete A Retrospective Meeting?

Reflect at a one- or two-week cadence, regardless of whether the team uses iterations. Reflect every time the team releases to the customer. (If your team uses continuous delivery, that might be too often.) Reflect at the start of the project to ask, "What do we want to keep, add, remove, or change from previous work we've done?" Reflect at the end of the project.

What is Relative Sizing?

Relative sizing uses two ideas to improve estimates: 1. the team compares story sizes (points) against what it's accomplished in the past (the relative part), and 2. it estimates using the wisdom of the team as a form of Wideband Delphi estimation. As everyone comments on the story and as people suggest a relative size, the team gathers better data and can therefore develop a better estimate.

What are some ways to show team progress?

Show working product. Provide feature charts to show what's done, what's added, and what remains. Show the number of requests the team has received (and maybe what they are) in addition to work on its board. Show what's working but not yet released to customers. Show different project measures that relate to the project's progress.

What is an Iterations Content Chart?

Shows you what you have completed in a given iteration. Part of a team's capacity is the features it can complete, and any defects the team fixes, or changes the team takes. That's what the iteration contents chart can show you.

What is an FDD Story Format?

Some action — the result — some object This is because not all stories arise from humans interacting with the product. Sometimes the product monitors its health and takes autonomous (non-human-initiated) or asynchronous actions.

What is a defect Escape?

Sometimes the team doesn't fully understand some aspect of a story. Or maybe the product owner didn't fully explain the acceptance criteria. Or maybe the product owner or the team made a mistake writing the story and the acceptance criteria. Any number of things might occur and a defect escapes the team, even though the story met the acceptance criteria and the product owner accepted it. When you measure the number of defects that escape over time, you can then perform a retrospective to see what you might do. In an agile approach, escaped defects are not the norm. If you see defects escape, address that as an impediment to fix.

What is the Agenda for Problem Solving Meeting?

Specify the location and participants. Send this out in advance so people have time to think. Check in with everyone. List the problem(s) of the week. You might find that people respond to "obstacle removal" or "impediment removal." Use terms that fit for your organization. Discuss each problem. Consider whether you need to timebox the discussion. If your team can't resolve the problem, ask if you need to escalate the problem, and to whom. If the team can't resolve this problem, put the problem on your kanban board or action-item list, with a time to resolve it. Don't let this work hide. It's WIP. Review any outstanding action items or kanban items you have not resolved. Adjourn the meeting.

What are spikes?

Spikes are timeboxed prototypes that provide the team information about the rest of the feature or the feature set.

What are Good Recommendations for Managing an iteration-based agile approach and meetings?

Start the iteration on a Wednesday after lunch. Conduct the one-hour timeboxed planning meeting right after lunch. Start the iteration. Consider standups every day just before lunch. On the middle Wednesday, conduct a one-hour timeboxed refinement meeting in the morning. On the last morning of the iteration, that next Wednesday, start a demo at 9 a.m. Conduct a two-hour retrospective from 10 a.m. to noon. Break for lunch. Start the next iteration after lunch.

What is a storyboard?

Story The smallest possible value to a specific user. It might not be sufficient to release by itself.

Should Stretch Goals be Used in Agile?

Stretch goals don't belong in estimates. They don't belong on agile teams, because the team's velocity is based on a sustainable pace.

What are some interpersonal qualities exhibited by successful agile team members?

Team members collaborate with each other. Team members can ask each other for help. Team members are adaptable, willing to work on whatever is next and possibly outside of their expertise. Do something good enough for now (as opposed to waiting for perfection). Create experiments to try something and receive feedback on the product or the team's process. Be willing to work outside their preferences as a generalizing specialist to help the entire team deliver.

What are the Things Needed to be able to Produce Accurate Estimates?

Teams can provide an accurate estimate if they understand: 1. their current reality (what the code looks like), 2. their typical speed (velocity and/or cycle time), and 3. how much work they think this feature will take. 4. If team members will be expected to multi-task? If any one of those things is unknown, their estimates will not be accurate. In addition, if the team members are supposed to multitask on features or projects, their estimates cannot be accurate.

What are some done traps?

Teams might not realize they encounter "done" traps. Here are three I've seen too often in teams: The team has no "done" criteria. It "all" has to be done before any of it can be released. The team requires "hardening" iterations or effort.

What is the Fault Feedback Ratio?

The FFR is the ratio of the number of rejected fixes (fixes that don't actually fix the problem) to the total number of fixes. My experience is that an FFR of more than 10% says the developers don't make enough progress on finding and fixing the problems. They spend their time trying to discover the cause(s) of the problems and creating even more tests. I've also seen this occur when fixing one problem uncovered more problems.

What are the Four Potential Costs for Delaying Work?

The company misses the potential sales from the introduction delay. The delay introduces lower maximum sales. The delayed introduction creates less overall demand, so the feature has less value in total. With less demand, the end of life might be earlier with a delay. Often, this is a function of not being able to capture the market at the optimum time. Since you don't have the customers, you have an earlier end of life.

What is the Teams WIP Limit when Swarming?

The entire team works on just one story at a time. The team's WIP limit is 1.

What does Mobbing Mean?

The entire team works together on one keyboard. Think of mobbing as team-pairing. See ​Mob on the Work​.

What are the Benefits of Ranking by Value Over Time?

The product owner might not even start work on this feature or feature set if the team can't finish it when the feature runs out of value. The team can deliver the most valuable work and not have to start work that's no longer valuable. The product owner might be able to have a conversation about which story is first, second, and third. That helps the product owner and the team break apart feature sets into smaller features.

What are the advantages of paperboard over electronic boards?

The team members can pass around a card or sticky to review, add/subtract, or rephrase. That's how people on the same team build the same mental model of the story or feature set. People don't move something to some sort of in-progress column without actually standing up from their desk, walking over to the board and moving it. Electronic tools make it too easy for the team members to say, "Yes, I'm done with that" or "I'm working on it" when neither state is true. Electronic tools can hide the details of the card. Often, the box is too small to see the story details or the acceptance criteria at a glance. Paper helps you create smaller stories, because the paper (cards or stickies) is small. When you start with paper, you can see which columns you need on your board and easily add or subtract them. Paper helps you limit the team's overall WIP. Paper creates a physical limit for what everyone sees, considers, and works on.

How do You Conduct a Stand up?

The team gathers around its board. (See ​Make Your Own Board​.) Each team member answers these questions inside a 15-minute timebox: What have I/we completed since the last standup? (If people work together, they might answer what "we" completed.) What am/are I/we working on now? What are my/our impediments? How can I/we help move the work to Done? The team facilitates itself. It might be a good idea for people to trade off who facilitates the standup. Remember, the standup is not a serial status meeting for the Scrum master or the agile project manager; the standup is for the team.

Agile teams fulfill these requirements?

The team has all the people (with their skills and capabilities) it needs to complete the work. The team does not change people for a given feature. The team has a shared goal for its project. The team "owns" its work. Members commit to their work and they own their artifacts, including the code and tests. The team does not change people inside an iteration. The team is stable, so the people can learn to work together and can learn their product area(s). If the team uses iterations, no one changes what the team commits to for that iteration.

What is the Value of Pairing, Swarming, and Mobbing?

The team limits its WIP, which helps it focus on getting work done. The team can learn together in swarming and does learn together in mobbing. The team collaborates, so it reinforces its teamwork. Team members learn how each other person works. They also learn who has expertise now, who might need which expertise, and how each of their colleagues learn. The team has multiple eyes on small chunks of work, so it gets the benefit of continuous review.

What are the seven practices of Servant Leadership

They are self-aware. They listen. They serve the people who work "for" them. (Keith calls this "changing the pyramid.") They help other people grow. They coach people, not control them. They unleash the energy and intelligence of others. They work to develop their foresight so they can act, not react.

What is a Burndown Chart?

They measure progress against time. It contains: 1. Report title called "Story Points Remaining" 2. Y Axis of Story Points 3. X axis of Time 4. A line to represent what has been completed. A burndown shows what you have completed against time. A burndown with the Ideal line emphasizes what the team did and what the team should be doing. The way to remember an x and Y Axis is as follows: "Y to the sky and x to the left."

What is the Process for Relative Sizing?

To effectively use relative sizing, first ask the product owner to create stories that are as small as the product owner can create. Make sure these stories are real user stories so the team can understand who will see the value in each story. Ask the team to group the stories by size, from the smallest to the largest. Keep similar-size stories together. The entire team decides how large the stories are. Assess the story sizes. Using the Fibonacci sequence (1, 2, 3, 5, 8, 13, and so on), assign all the smallest stories to the size 1 bucket. The next-sized stories are a 2 and the next are a 3. Continue until the team agrees on the relative sizes of the stories. (See Agile Estimating and Planning [Coh05].) Once the team agrees on the relative size, take the stories estimated as 2. Do all the 2 stories look like they're about the same size? If so, now estimate the duration for the 2 stories. If the team thinks all the 2 stories will take about 10 person-hours, you now know how long the 1 stories will take. Divide the duration for the 2 stories by 2 to derive the duration for the 1 stories. In this example, our 1 stories would take five hours. Ask yourself whether that makes sense. If so, you now have the factor to use to multiply against all the other relative sizings. If you see you have stories larger than an 8, size up to 13 and then use 20, or 40 for very large efforts. (The reality is that no one understands the size of anything past 13, but we can use these numbers in a different way later.)

What does Pairing Mean?

Two people work together on one story, on one machine with one keyboard. Developers might pair-program. A developer and a tester might pair together to review performance. Two testers might pair-test. Any two people working together are a pair. When team members pair in person, they work on one item—on one machine, with one keyboard. The pair trades off who types and who looks. The person typing is called the driver. The person looking is the navigator.

What is the Build-Measure-Learn Feedback Loop?

When product owners create MVPs to test out the minimum features. 1. Ideas 2. Build 3. Product 4. Measure 5. Data 6. Learn

What is the SCARF Model and what is it used for?

Used to increase collaboration and influence. Status - the relative importance to others. Certainty - the ability to predict future. Autonomy - the sense of control over events. Relatedness - the sense of safety with others. Fairness - the perception of fair exchanges.

What is the Definition of Velocity?

Velocity is a rate of change coupled with a direction. Velocity is not acceleration. The more your story size varies, the more difficult it is to use velocity as any kind of a predictive measure for what your team can finish. Think velocity as capacity. Your team can, on average, deliver some number of stories, some number of fixes, maybe something else. Velocity is not acceleration. The more your story size varies, the more difficult it is to use velocity as any kind of a predictive measure for what your team can finish.

What are Good Recommendations for Managing a Flow Based Agile approach and meetings?

Walk the board as a team if the team doesn't mob or swarm every day just before lunch. Create a cadence for its backlog-refinement activities. Create a cadence for its retrospective activities. Decide about demos as part of its working agreements. For example, the team might demo every story as it's completed. The team might demo the product to sponsors or customers on a cadence.

What are the Two Reasons to Use Rolling Wave Planning?

We might get far enough into a feature set and realize we don't need to do any more, either at all or for this project. Agile approaches invite change. With rolling-wave roadmaps, we can show people how things might change.

Describe the Mobon the Work Process?

When a team mobs on the work,[16] it combines swarming with some of the pairing ideas. The team has a WIP limit of 1. And the team mobs around one keyboard and large screen, so everyone can see what the driver is typing at all times. The team changes drivers on a frequent basis, say, every 10 minutes. Many teams use a very large television as a monitor or hook up the computer to a projector. Whatever you do, make sure the team is comfortable: everyone has chairs that work for them. Many teams who mob also use hand sanitizer as a matter of course.

What is the Three Amigos Approach to Refine Stories?

When teams use the Three Amigos, they split into triads of one developer, one tester, and one product owner or business analyst. The idea is that each person has a unique perspective on the possible story: The developer thinks about how to implement the story. The tester thinks about what can go wrong. The product owner or business analyst thinks about what the customer or business wants to accomplish with this story.

What is the promise of the #NoEstimates philosophy?

Working without estimating and instead working by value. Sometimes there's value in estimates. You can provide a ballpark, an order of magnitude about how long this project or feature set will take. However, if you are working in an agile way and you have a team that is able to maintain a steady throughput of value, you might not need to estimate at all.

How do You Manage Work Other than Features?

Write user stories to explain the acceptance criteria for a defect. Gather several related defects together and write a user story to explain them. Add the defects to the backlog for a given iteration as part of what the team will deliver.

How do you overcome the trap where team members are wary of collaboration?

You can ask people to experiment in short timeboxes for how they can work together. If your organization still rewards people only for individual work, your attempts to use agile approaches are likely to fail. You have an impediment to an agile culture. Add this impediment (individual rewards) to your impediment list, and escalate that to management. See ​Visualize Problems with a Board​. Consider discussing the difference between flow efficiency and resource efficiency, as discussed in ​Managers Move from Resource-Efficiency to Flow-Efficiency Thinking​, with team members. Conduct one-on-ones to understand each person's concerns. Once you do, you can start to address those concerns.

What is the Value of Continuous Integration?

You can see what you're done with and what's still in progress. Developers can check to see if they broke the build. Automated smoke tests can check that the product's performance or reliability still works the way everyone expects. Other people can use what you finished.

Can I Use Tasks or Technical Stories Instead of User Stories?

You may have seen story advice that tells the team to break the work into tasks, such as setting up a database, or creating tests, or some other function-based work. Don't fall for that advice. Don't create tasks or technical stories. The story is too large if you need to create tasks or technical stories. Teams create tasks because they don't understand the story's user—who the value is for—or if the story is quite large and the first item of value is not clear to the team. The team thinks it will save time by creating what it calls technical stories or tasks.

What are some team traps?

Your team is a component team. Everyone on your team is a narrow expert. The developers and testers don't work together, but rather in staggered iterations. The team's membership isn't stable, so the team has trouble learning to work together. The team pushes to finish work. The team cannot solve its own problems. Team members have a history and culture of individual work, not collective work.

How do you create safety on teams?

encourage learning from small experiments, use clear and direct language, admit when we don't know, acknowledge when we fail, and set boundaries for what is a personal or team decision and what is not.

What does FDD mean?

feature-driven development (FDD)