Quiz: SDLC and Agile Methodologies
Test your understanding of the software development lifecycle, Agile frameworks, Scrum ceremonies, backlog management, CI/CD, and iterative product development with these review questions.
1. Which sequence correctly represents the phases of the software development lifecycle (SDLC)?
- Requirements gathering, design, implementation, testing, deployment, maintenance
- Design, requirements gathering, testing, implementation, deployment, maintenance
- Implementation, design, requirements gathering, deployment, testing, maintenance
- Requirements gathering, implementation, design, testing, maintenance, deployment
Show Answer
The correct answer is A. The SDLC follows a structured sequence: requirements gathering (defining what the software should do), design (planning architecture and interfaces), implementation (writing code), testing (verifying correctness), deployment (releasing to users), and maintenance (fixing bugs and evolving the product). The chapter emphasizes that while different methodologies organize these phases differently, this is the typical ordering that teams follow.
Concept Tested: Software Dev Lifecycle
2. What is the fundamental limitation of the Waterfall methodology that led to the development of Agile approaches?
- Waterfall requires too many team members and is expensive to staff appropriately
- Waterfall does not include a testing phase, leading to poor software quality
- Waterfall lacks documentation standards, creating confusion among development teams
- Waterfall locks requirements early, making it impossible to incorporate user feedback until after launch
Show Answer
The correct answer is D. The chapter states that the fundamental problem with Waterfall for most software products is that "you cannot fully specify requirements for something users have never seen." Because Waterfall locks requirements early in the process, teams cannot incorporate user feedback until after the full product is delivered. This rigidity, combined with big-bang delivery and change resistance, drove the development of Agile approaches that embrace iterative feedback.
Concept Tested: Waterfall Methodology
3. A product owner presents prioritized backlog items, the team breaks them into tasks, and they agree on a single overarching objective for the upcoming sprint. Which Scrum ceremony is being described?
- Sprint retrospective
- Daily standup
- Sprint review
- Sprint planning
Show Answer
The correct answer is D. Sprint planning is the ceremony that kicks off each sprint. The chapter describes it as answering three questions: "What can we deliver this sprint?" (product owner presents priorities), "How will we do the work?" (team breaks items into tasks), and "What is our sprint goal?" (a single overarching objective). Sprint planning is where strategy meets execution, making it one of the most important meetings a technical PM attends.
Concept Tested: Sprint Planning
4. Why does the chapter warn against comparing velocity between different Scrum teams?
- Different teams use different sprint lengths, making comparison mathematically invalid
- Story points are relative to each team's calibration, so point values are not equivalent across teams
- Velocity includes both completed and incomplete stories, which vary by team counting method
- Some teams track velocity in hours while others use story points, creating unit conflicts
Show Answer
The correct answer is B. The chapter explicitly warns: "Never compare velocity between teams - story points are relative to each team's calibration." Because story points represent relative effort within a team's own estimation framework, a 5-point story on one team may represent very different work than a 5-point story on another team. Using velocity as a cross-team comparison or performance metric incentivizes point inflation rather than actual productivity improvement.
Concept Tested: Velocity Tracking
5. Your team currently uses Scrum but is considering switching to Kanban. The team primarily handles unpredictable support requests and production incidents rather than planned feature work. Which characteristic of Kanban makes it more suitable for this type of work?
- Kanban prescribes specific roles like Product Owner and Scrum Master for clear accountability
- Kanban uses velocity tracking to forecast when support tickets will be resolved
- Kanban allows continuous flow with new items entering anytime capacity opens, rather than waiting for the next sprint
- Kanban requires sprint retrospectives that help teams improve their incident response process
Show Answer
The correct answer is C. The chapter's Scrum vs. Kanban comparison table shows that Kanban uses continuous flow rather than fixed sprints, and planning is "just-in-time, as capacity opens" rather than at sprint boundaries. For unpredictable support work, this is ideal because the team does not have to wait for a new sprint to begin working on urgent issues. The chapter notes that Kanban is "best for support teams, maintenance, unpredictable work," making it the right fit for this scenario.
Concept Tested: Kanban Method
6. What is the key difference between continuous delivery and continuous deployment?
- Continuous delivery requires a human to make the final release decision while continuous deployment automatically releases every passing change
- Continuous delivery uses automated tests while continuous deployment relies on manual testing
- Continuous delivery applies only to web applications while continuous deployment works for all software types
- Continuous delivery deploys to a staging environment while continuous deployment deploys directly to development servers
Show Answer
The correct answer is A. The chapter clearly distinguishes the two: with continuous delivery, "every change that passes automated tests could be deployed to production; a human makes the final decision." With continuous deployment, "every change that passes automated tests is automatically deployed to production; no human gate." Both build on CI, but the distinction lies in whether a human decision point exists before code reaches production.
Concept Tested: Continuous Delivery
7. You are writing acceptance criteria for the user story: "As a team administrator, I want to set role-based permissions so that I can control who can edit sensitive data." Which of the following uses the correct Given-When-Then format as described in the chapter?
- The system should allow administrators to set permissions for team members with different role levels
- Given I am a team administrator viewing the permissions page, when I assign the "Editor" role to a team member, then that member can edit data and members without the role cannot
- Administrators need permissions management so they can control data access across the team
- When permissions are set, the system must validate that at least one administrator role remains active at all times
Show Answer
The correct answer is B. The chapter specifies that acceptance criteria are typically written using the Given-When-Then format: "Given [some precondition], When [some action], Then [expected result]." Option B follows this structure precisely with a precondition (administrator viewing permissions page), an action (assigning Editor role), and a testable expected result (member can edit, others cannot). The other options are either vague requirements, functional descriptions, or validation rules that lack the structured format.
Concept Tested: Acceptance Criteria
8. A technical PM wants to release a new checkout flow to 5% of users, monitor error rates and conversion metrics, and then gradually increase exposure to 25%, 50%, and 100%. Which technique enables this approach without requiring separate deployments for each stage?
- Sprint planning with phased story prioritization
- Continuous integration with branch-based deployment
- Feature flags with gradual rollout capability
- Release management through quarterly release trains
Show Answer
The correct answer is C. The chapter describes feature flags as enabling "gradual rollouts - enable a feature for 5% of users, monitor metrics, then increase to 25%, 50%, and finally 100%." Feature flags decouple deployment from release, allowing code to be deployed to production but only exposed to selected user percentages. This gives PMs control over the user experience without requiring engineering to perform a new deployment at each stage. The chapter emphasizes that feature flags "shift the release decision from engineering to product."
Concept Tested: Feature Flags
9. During daily standups, you notice that the same backlog item has been reported as "in progress" for four consecutive days. Based on the chapter's guidance about the PM's role in standups, what does this pattern most likely indicate?
- The Scrum Master is failing to remove impediments and should be replaced
- The developer is not working efficiently and needs closer supervision during the sprint
- The team's velocity calculation is incorrect and needs to be recalibrated
- The item may have hidden complexity or scope creep that was not identified during sprint planning
Show Answer
The correct answer is D. The chapter specifically instructs PMs to listen for signals during standups, including: "Are the same items 'in progress' for multiple days? (May indicate hidden complexity or scope creep)." The PM's role in standups is to listen for patterns rather than manage tasks or micromanage team members. The chapter frames this as a diagnostic signal that warrants investigation, not a performance issue to be addressed through supervision.
Concept Tested: Daily Standups
10. A team is building a new project management tool and plans to include task lists, Gantt charts, resource allocation, time tracking, invoicing, and third-party integrations in their first release. Based on the chapter's discussion of MVP anti-patterns, which mistake is this team making?
- The throwaway MVP, building something so minimal that no code can be reused
- The internal MVP, testing only with stakeholders who cannot represent real users
- The everything MVP, including too many features and defeating the purpose of minimum scope
- The endless MVP, continuously adding features and never launching to actual users
Show Answer
The correct answer is C. The chapter identifies "the everything MVP" as an anti-pattern where the team tries to "include too many features, defeating the purpose of minimum scope." The scenario describes six major feature categories in a first release, which contradicts the MVP principle of finding "the smallest scope that still delivers genuine value." The chapter emphasizes that an MVP is a "deliberate, strategic choice about the minimum functionality needed to test whether your product solves a real problem," and the key word is "viable," not "comprehensive."
Concept Tested: Minimum Viable Product