41. Three projects in parallel
A team can do three equal 4-week projects one after another, or all three in parallel, finishing all at week 12. What is the main gain of doing them in sequence?
- A.There is no difference in when value arrives
- B.Total effort drops to just 4 weeks
- C.Value comes at weeks 4 and 8, not all at 12
- D.All three projects finish at week 4
Show answer
Answer: C. Value comes at weeks 4 and 8, not all at 12
In sequence, project 1 delivers at week 4 and project 2 at week 8, instead of all at week 12. Parallel work also adds switching costs, so it usually finishes even later than week 12.
42. Comparing team velocity
Leadership wants to rank five Scrum teams by velocity and reward the highest. What is the best response?
- A.Push back: story points are relative to each team, so ranking invites point inflation; use outcomes and flow measures instead
- B.Agree, and standardise one point as eight hours across teams
- C.Agree, but only reward teams whose velocity is rising
- D.Agree, because velocity is the best productivity measure
Show answer
Answer: A. Push back: story points are relative to each team, so ranking invites point inflation; use outcomes and flow measures instead
Each team sizes points differently, so a velocity of 40 in one team is not more than 30 in another. When velocity becomes a target, teams inflate estimates and the metric stops helping forecasting. Outcomes, cycle time, throughput and quality are better ways to discuss performance.
43. Commitments for each artifact
In the 2020 Scrum Guide, each artifact has a commitment. Which pairing is correct?
- A.Product Backlog: Product Goal; Sprint Backlog: Sprint Goal; Increment: Definition of Done
- B.Product Backlog: Definition of Done; Sprint Backlog: Product Goal; Increment: Sprint Goal
- C.Product Backlog: Sprint Goal; Sprint Backlog: Definition of Done; Increment: Product Goal
- D.Product Backlog: Roadmap; Sprint Backlog: Velocity; Increment: Release plan
Show answer
Answer: A. Product Backlog: Product Goal; Sprint Backlog: Sprint Goal; Increment: Definition of Done
The Product Goal gives the Product Backlog direction, the Sprint Goal is the single objective of the Sprint Backlog, and the Definition of Done says when work becomes part of the Increment. These commitments add focus and transparency to each artifact.
44. Velocity as a target
Leadership sets each team a target of "10% more story points every sprint". Three sprints later, velocity is up 30% but customers see no faster delivery. What most likely happened?
- A.Teams became 30% faster and customers did not notice
- B.The burndown chart was set up incorrectly
- C.Teams inflated estimates, so points rose without more value
- D.The Product Owner stopped accepting stories
Show answer
Answer: C. Teams inflated estimates, so points rose without more value
When a measure becomes a target, people optimise the measure (Goodhart's law). Points are relative and team-owned, so the easiest way to "grow" velocity is to estimate higher. Measure outcomes such as lead time or customer value instead.
45. Monte Carlo forecasting
A Kanban team wants to answer "When will these 40 items be done?" using a Monte Carlo forecast. What input does it need?
- A.A story point estimate for every one of the 40 items
- B.Historical throughput samples, such as items finished per week
- C.The planned hours of each team member
- D.The average size of past epics in points
Show answer
Answer: B. Historical throughput samples, such as items finished per week
Monte Carlo simulation repeatedly samples past throughput to simulate many possible futures. The result is a range with probabilities, for example "85% chance by 14 November", without estimating each item.
46. A service level expectation
A Kanban team publishes an SLE: "85% of items finish within 9 days." An item has been in progress for 7 days. What should the team do?
- A.Wait until day 9, as the SLE is not yet breached
- B.Treat it as at risk and act now, since it is near the SLE
- C.Move it back to To Do to reset the clock
- D.Ignore it; 15% of items may take longer
Show answer
Answer: B. Treat it as at risk and act now, since it is near the SLE
An SLE is a forecast of how long an item should take, and work item age is checked against it daily. An item at day 7 of 9 needs attention now, such as swarming or removing a blocker, before it becomes a slow outlier.
47. A severe bug mid-sprint
In the middle of a sprint, a bug stops customers in the UAE from paying with cards. The team is the only one who can fix it. What is the best approach?
- A.Add it to the Product Backlog for the next Sprint Planning
- B.Cancel the sprint and start a new one just for the bug
- C.Fix it only after the Sprint Goal has been fully met
- D.Fix it now and agree with the PO what sprint scope to drop
Show answer
Answer: D. Fix it now and agree with the PO what sprint scope to drop
A critical production issue usually outranks planned work. The Scrum Guide allows scope to be renegotiated with the Product Owner as more is learned, so the team fixes the bug and agrees what to drop, keeping the Sprint Goal if possible.
48. Component teams or feature teams
An e-commerce company has separate frontend, backend and database teams. Every customer feature needs all three and takes 3 sprints because of hand-offs. What change best addresses this?
- A.Add a dependency manager to track hand-offs
- B.Form cross-functional feature teams that can deliver end to end
- C.Make sprints longer so all three teams finish together
- D.Ask each component team to estimate in hours
Show answer
Answer: B. Form cross-functional feature teams that can deliver end to end
Component teams create dependencies for nearly every feature, so value waits in queues between teams. Feature teams own a customer outcome across layers, which cuts hand-offs; a tracker only makes the waiting visible.
49. Conway's law in practice
A company splits its product into "payments team" and "orders team", and soon the system has two loosely joined services with a messy interface between them. Which idea explains this?
- A.Parkinson's law: work expands to fill the time available
- B.Brooks's law: adding people to a late project makes it later
- C.Goodhart's law: a measure that becomes a target stops being useful
- D.Conway's law: systems mirror the communication structure of the organisation
Show answer
Answer: D. Conway's law: systems mirror the communication structure of the organisation
Conway's law says designs copy the communication structure of the groups that build them. Agile organisations use this on purpose (the "inverse Conway manoeuvre") by shaping teams around the architecture they want.
50. A hardening sprint every release
A team runs four feature sprints followed by a "hardening sprint" to test, fix bugs and integrate before each release. What does this usually reveal?
- A.The team is mature enough for longer sprints
- B.The Product Owner is ordering the backlog well
- C.This is the standard Scrum release pattern
- D.The Definition of Done is too weak, so undone work piles up
Show answer
Answer: D. The Definition of Done is too weak, so undone work piles up
If testing and integration are needed after "done" work, each sprint's Increment was not truly usable. Strengthening the Definition of Done so this work happens inside each sprint reduces risk and makes velocity honest.
51. PO and Scrum Master as one person
To save cost, a startup asks one person to act as both Product Owner and Scrum Master. What is the strongest concern?
- A.The Scrum Guide forbids anyone from holding two accountabilities
- B.The team would then also need a separate project manager
- C.It mixes deciding what to build with protecting how the team works
- D.Velocity can no longer be measured with a combined role
Show answer
Answer: C. It mixes deciding what to build with protecting how the team works
The Product Owner pushes for value and scope, while the Scrum Master protects the process and team health, including from scope pressure. One person doing both often loses the balance; it is a risk to manage, not a rule broken.
52. Large-Scale Scrum (LeSS)
In basic LeSS, what is the structure for up to about eight teams?
- A.One Product Owner per team, with a chief PO above
- B.Each team runs its own sprint length and backlog
- C.One Product Owner, one backlog, one shared sprint
- D.A release train led by a Release Train Engineer
Show answer
Answer: C. One Product Owner, one backlog, one shared sprint
LeSS keeps Scrum simple at scale: one product, one Product Owner, one Product Backlog, one Definition of Done and a common sprint. Release trains and RTEs are SAFe concepts.
53. The Nexus Integration Team
In the Nexus framework for 3–9 Scrum Teams, what is the Nexus Integration Team accountable for?
- A.Writing all the code that joins the teams' work
- B.Approving every story before it enters a sprint
- C.Managing the budget and staffing of the Nexus
- D.Ensuring an integrated Increment every sprint
Show answer
Answer: D. Ensuring an integrated Increment every sprint
The Nexus Integration Team is accountable for an integrated Increment each sprint. It coaches and removes integration impediments, but the Scrum Teams still do the integration work.
54. Copying the Spotify model
A bank renames its teams "squads", "tribes" and "chapters" after reading about Spotify, but nothing else changes. Why is this usually disappointing?
- A.Spotify's model only works for teams under ten people
- B.The terms are trademarked and cannot be used by others
- C.Squads are not allowed to use either Scrum or Kanban
- D.It copies labels without the culture and practices behind them
Show answer
Answer: D. It copies labels without the culture and practices behind them
The "Spotify model" described how one company worked at one point in time, and Spotify itself says it kept changing. Renaming teams without changing decision rights, alignment and engineering practices gives little benefit.
55. Water-Scrum-Fall
A company does six months of requirements, then Scrum sprints for build, then three months of UAT and release. What is the main weakness?
- A.Sprints are far too short for real development work
- B.User feedback still comes only at the end, so risk remains
- C.The team will end up with too many Scrum Masters
- D.Requirements will change too often for sprints to work
Show answer
Answer: B. User feedback still comes only at the end, so risk remains
Sprints in the middle improve team flow, but releasing and learning from users still happens only after months. Agile's main risk reduction comes from frequent, usable releases and feedback.
56. Stable teams vs resource pools
To keep everyone busy, a PMO moves developers between three teams every sprint. Which effect is most likely?
- A.Velocity becomes unreliable and team performance drops
- B.Each team gains more ideas and grows faster
- C.Forecasts get more accurate thanks to flexibility
- D.Retrospectives are no longer needed
Show answer
Answer: A. Velocity becomes unreliable and team performance drops
Stable, long-lived teams build shared context and trust, which drives performance and makes velocity a usable forecasting signal. Constant reshuffling resets the team to "forming" and wipes out that learning.
57. A misleading agile metric
A VP reports "Our 12 teams delivered 3,400 story points this quarter, up 20%." Why is this a weak measure of success?
- A.It should be reported per month instead of per quarter
- B.Points are team-relative and say nothing about outcomes for customers
- C.Story points can only be reported for one team
- D.The number is too large to be accurate
Show answer
Answer: B. Points are team-relative and say nothing about outcomes for customers
Points are not comparable across teams and are easy to inflate, so summing them means little. Better measures look at outcomes, such as customer adoption, lead time and quality.
58. The agile testing quadrants
In Brian Marick's agile testing quadrants, where do exploratory testing and usability testing sit?
- A.Business-facing tests that critique the product (Q3)
- B.Technology-facing tests that support the team (Q1)
- C.Business-facing tests that support the team (Q2)
- D.Technology-facing tests that critique the product (Q4)
Show answer
Answer: A. Business-facing tests that critique the product (Q3)
Q1 is unit and component tests; Q2 is functional tests and examples; Q3 is business-facing tests that critique the product, such as exploratory and usability testing; Q4 covers performance and security. The quadrants help plan a balanced test strategy.
59. Shown in review but criteria not met
In the sprint review the PO finds one of five acceptance criteria not met. The team says it is 90% done and asks to count the points. What should happen?
- A.Count 90% of the story's points this sprint
- B.Count the points and fix it next sprint
- C.Not done: no points, and the work goes back to the backlog
- D.Delete the failed criterion so the story passes
Show answer
Answer: C. Not done: no points, and the work goes back to the backlog
In Scrum a story is done or not done. Counting partial points inflates velocity and hides work left. The unmet criterion stays, and the PO re-ranks the remaining work, which may be quick to finish next sprint.
60. Cycle time from WIP and throughput
A Kanban team has 12 stories in progress on average and finishes 4 stories a week. Using Little's Law, what is the average cycle time?
- A.48 weeks
- B.3 weeks
- C.0.33 weeks
- D.8 weeks
Show answer
Answer: B. 3 weeks
Little's Law says average cycle time = average WIP / average throughput = 12 / 4 = 3 weeks. Cutting WIP while keeping throughput the same shortens cycle time, which is why Kanban teams set WIP limits.
