Final Exam Study Flashcards
(31 cards)
Project Management Plan
PMBOK - the document that describes how the project will be executed, monitored, and controlled.
Common Elements
Introduction or overview of the project
Description of how the project is organized - Roles & responsibilities
Management Processes -
Work to be done ◦ Project Schedule ◦ Budget information
Technical processes used on the project - Technical infrastructure & technologies to be used
A baseline is the approved project management plan plus approved changes
Scrum Planning
- Can’t get the plans right up front
- Up-front planning is helpful without being excessive
- Keep planning options open until last possible moment (just-in time planning)
- Focus more on adapting/re-planning than conforming to a plan
- Correctly manage the planning inventory
- Favor small & more frequent releases
- Plan to… learn fast (Fail fast) & pivot when necessary
Source Control
version control system for tracking changes in computer files & coordinating work on those files among multiple people
Product Planning
- The Product Owner is crucial in the initial product planning phase, collaborating with stakeholders and often supported by specialists like Systems Architects and UI/UX Designers.
- Ideally, the entire Scrum team participates in this phase to offer feedback and reduce later handoffs, though full team engagement typically awaits organizational funding post-envisioning.
3.Sprint 0 involves creating a high-level Product Backlog with Epics and a Product Roadmap for incremental releases, based on the product vision or scope from the Statement of Work.
- To aid in planning and understanding, additional artifacts like wireframes, flowcharts, and personas may be developed alongside the Product Backlog and Roadmap.
Scope
Scope refers to all the work involved in creating the products of the project (the What) and the processes used to create them (the How)
A deliverable is a product produced as part of a project
Project scope management -
includes the processes involved in defining and controlling what is or is not included in a project
PBIs
User Stories / Requirements
Product Backlog
Everything to be built over a project.
Epics
Stories
Sprint Backlog
All the stories to be worked on / completed during a given sprint.
Release Planning
We don’t want to set overly aggressive deadlines
Each release should focus on minimum releasable features (MRFs)
◦ “Must-have” functionality for users to do their task, while meeting customer value & quality expectations
MVP
Minimum Viable Product
Prioritizing
PBIs that deemed to be most important to key stakeholders will be placed at the top of the Product Backlog
MoSCoW
Must Have
Should Have
Could Have
Will not Have
Release Naming
Release Stages:
Alpha
- software that is in the early stages of development. Possibly environment from continuous deployment
Beta
-feature complete software, but not ready for release as it’s not fully regression tested. Possibly a result of a release after a sprint
Release Candidate
-Has gone through several beta test cycles. Beta testing is now conducted at client site or in future production environment. Has potential to be a final product soon.
Production Release
- Stable Release or Final Release or Live Release
major.minor.build.revision
major = a milestone release or large change
minor = potentially a significant change, but not one that requires the major # to be changed
build = incremental build of solution that happen at intervals of a project. Like at the end of sprints
revision = change or edit to an existing build to resolve an issue
Example: 2.1.3.1 or 2.1
Production release versions of initial software are 1.0
Product Roadmap
Key Components:
Release Names
Dates of each Release
- Should show the timespan it will take for each release
Deliverables
– product produced as part of a project
Features
-What will be in each of the deliverables Can use Epics/Features from the Product Backlog
PERT
Create 3 estimates of duration
(ex: workdays) to complete each activity
Optimistic, Most likely, Pessimistic
Story Points
Uses Relative Size Estimation
There is no direct correlation between hours & story points
Fibonacci
1
2
3
5
8
13
20
40
100
Planning Poker
Good for estimating small sets of stories
Full Scrum team participates
Wall Estimation
Good for managing large raw product backlogs
Place Stories on The wall:
Height of story placement determines priority
-Higher = more importance
-Done by Product Owner & Stakeholder if present
Horizontal placement represents size
-Stories on left are smaller than the bigger -stories on the right
-Done by dev team
Velocity
The amount of work completed in each sprint
Essential for Sprint Planning meeting
Helps determine teams capacity of work it can commit in upcoming sprints
Used to answer:
- When will the project be done?
- How much will it cost?
Definition of Ready
1 product owner that owns Product Backlog
Before heading into a Sprint, the Product Backlog’s top PBIs should be in a “Ready State”, meaning:
-Stories are sized appropriately (small & granular)
-Business value is clearly articulated in the stories
-Details can sufficiently be understood by developers
-Acceptance Criteria is clear & testable
-Top stories are prioritized in way they are to be executed
Sprint Planning
To determine the most important sub-set of PBIs to build in the next Sprint, the entire Scrum team performs sprint planning.
Just-in-time activity that takes place at the beginning of each Sprint:
-Timebox of 1 hour per weeks in a Sprint
Product Owner tells team on Sprint Goal
PO + Team negotiate what goes into a sprint
Dev Team decides what goes in sprint based on estimated velocity / capacity
Tasks
Sprint Execution
Is the work the team performs to meet Sprint Goal
Starts after Sprint Planning — Ends when Sprint Review Starts (last day of sprint)
-The dev team self organizes + self assigns work/tasks.
-Scrum Master remains as Agile coach, questioner, and impediment remover.
-Product Owner is available to:
clarifys ?’s
review work + provide feedback
verify acceptance criteria of PB is met
grooms PB of next sprint
interacts w/ stakeholders + maintain relationship
Swarming - divide + conquer - parallel work
Is a mini SDLC w/ all phases
Scrums
Sprint Burndown Chart
Release Burndown Chart
Grooming
To ensure top PBIs are in a “ready state” prior to each Sprint, they must be proactively managed.
-Perform grooming as ‘Just-in-time planning’
-Don’t want to plan further in advance than necessary
-Grooming is an ongoing collaborative effort, led by the one grooming decision maker:
-the Product Owner (PO), who is constantly grooming throughout the project
PO could/should include the Scrum Master & development team (analysts & devs)
Grooming entails 3 principal activities:
-Creating & Refining PBIs (progressive refinement)
-Prioritizing PBIs
-Estimating PBIs
Performing Change Control
View managing a project as a process of constant communication & negotiation
Overly Communicate w/ stakeholders
Stakeholders want indication + paper trail
