Agile PMP Terms Flashcards
1
Q
100-Value Method
A
- stakeholders are allotted 100 points to spend on features
- points are assigned to the most important requirements
- can be private or public voting
2
Q
Acceptance Test-Driven Development (ATDD)
A
- sometimes called FIT: framework for integrated testing
- testing is focused on business requirements and is all about desired behavior
- entire team gets together and discusses the acceptance criteria for a work product
- team creates the tests which allows the team to write just enough code and automated tests to meet the criteria
- distill the test in a framework friendly format
- develop code until it passes
- demo
3
Q
Acceptance Testing
A
- test to determine acceptability of the results for a specific requirement, specification, or contract requirement
4
Q
Adaptive Leadership
A
- directive: during forming stage of team development
- high directive behavior
- low supportive behavior
- coaching: during storming stage of team development
- high directive behavior
- high supportive behavior
- supporting: during norming stage of team development
- low directive behavior
- high supportive behavior
- delegating: during performing stage of team development
- low directive behavior
- low supportive behavior
5
Q
Adaptive Life Cycle (Agile)
A
fixed schedule and fixed costs; scope is broadly defined with the understanding it will be refined throughout the project * Scrum and Agile are the most common * customer’s requirements are documented and prioritized in backlog which can be adjusted * utilizes kanban board * work is planned in short increments to allow customer to change and reprioritize * example: a software project would have each phase include high-level feasibility, design, and planning followed by short, iterative phases of detailed design, coding, testing, releasing
6
Q
Affinity Estimating
A
- product owner, scrum master, and team participate
- group items/user stories into like groups
- features go under those functions
- also can group by story points or size of stories
- allows for triangulation in terms of knowing how much time there is in the sprint and the size of the stories for estimating purpose
- also allows to check that the story points awarded to each story are roughly equal
- sticky note system
- team finally estimates how many points can be done in an iteration
7
Q
Agile Charter
A
- authorizes the project and project manager
- acknowledges that change is likely
- includes
- vision statement
- team constitution
- code of conduct
- communication rules
- definition of done and key success factors
- defines
- who will be engaged
- what the project is about
- where the project will take place
- when the project will start and end
- one of the constraints is schedule
- why the project is being chartered
- how the project goals will be achieved
8
Q
Agile Communication Planning
A
- communication management plan
- transparency is paramount
- face-to-face is always the best method
- what stakeholders expect in terms of communication
- performance reporting
- how often
- face-to-face communication with stakeholders is preferred in Agile
- what technologies will be used
- what methods will be used
- what regular meetings can be scheduled in advance
9
Q
Agile Contracts
A
- contracts can be a form of constraint in projects because they are not typically not flexible
- contracts usually constrain time, cost, and scope but in Agile scope is variable
- always keep in mind customer collaboration in contracting because they are more involved in Agile projects than predictive
10
Q
Agile Life Cycle
A
requirements are dynamic, activities repeated until correct, frequent small deliveries, and the goal is customer value via feedback
11
Q
Agile Manfesto
A
* individuals and interactions over processes and tools * working software over comprehensive documentation * customer collaboration over contract negotiation * responding to change over following a plan
12
Q
Agile Project Sponsor
A
- authorizes the project
- signs the project charter
- has authority to authorize use of resources
- main advocate for the project and share the project vision
- give direction to product owner
- determine value on time and budget constraints
13
Q
Agile RFP
A
- request for proposal that needs to specify Agile methodology that will be used
- buyer might need to educate the vendor about Agile practices
- contracts can be difficult because contracts do not welcome change but Agile does
14
Q
Agile Stakeholder Engagement
A
- engage and empower business stakeholders
- establish shared vision and understanding of success
- share information frequently and provide transparency
- form working agreements for participation
- assess organizational changes to maintain a stakeholder engagement
- use collaborative decision-making and conflict resolution skills
- balance certainty and adaptability
15
Q
Agile Teams
A
comprised of cross-functional team members, product owner, and team facilitator (servant leader); ideally three to nine members in a team and collocated; members are 100% dedicated to the team; teams are self-managed; composed of generalists and specialists; have a stable work environment
16
Q
Architectural Spike
A
- a timeboxed effort to test the approach
- usually early in the project within an iteration
- test the environment and the development set-up
- prevents having future iterations built on unstable architecture
17
Q
Attractive Quality
A
- Kano category of customer preference
- nice to have but not required features
18
Q
Backlog Refinement Meeting
A
- product owner works with team to prepare some stories for the upcoming iterations
- team learns about potential challenges or problems in the stories
- product owner can request a spike if unsure about dependencies and risks
- team should not spend more than one hour per week doing backlog refinement
19
Q
Burndown Chart
A
- shows where the project is going over time
- story points are on the y axis while time is on the x axis;
- one line represents the plan while another represents the story points remaining
- could encourage team to rush to meet the acceptance criteria
- shows the effect of team members multitasking, working on stories that are too large, or having team members out of the office
- type of capacity measure
20
Q
Burnup Chart
A
- show the work that has been completed
- story points are on the y axis and time is on the x axis
- one line represents the plan while another represents the story points done
- allows team to see what they have accomplished which helps them proceed to the next piece of work
- type of capacity measure
21
Q
Candidate Story
A
potential user story that comes from the perspective of a user or customer
22
Q
CARVER
A
acronym to measure the goals and mission of the project with each letter meaning: Criticality, Accessibility, Return, Vulnerability, Effect, and Recognizability
23
Q
Caves
A
- work spaces for alone time and thinking in an Agile work environment
24
Q
Ceremony
A
meeting conducted during an Agile project that consists of daily stand-up, iteration planning, iteration review, and iteration retrospective.
25
Change-Driven Life Cycle
uses iterative, incremental, or adaptive development life cycles and have varying levels of early planning for scope, schedule, and cost; projects can use a combination of incremental and iterative \* incremental \* iterative \* agile
26
Coaching
* talk through the problem instead of telling them what to do
* guarantee safety
* partner with managers
* create positive regard
27
Coarse Grained Requirements
* keep the overall design balanced
* delays decisions on implementation details until the last responsible moment
* not spending a lot of time polishing backlog until it's time
* no value in polishing user stories or requirements that might change or be eliminated from the backlog
28
Collaborative Communication Model
* two-way communication model that is interactive
* collaborative communication happens in daily stand-up
29
Collective Code Ownership
* core practice of XP
* any pair of developers can improve or amend the code
* improve defect resolution
* discover mistakes before it gets to customer
* requires courage because mistakes are viewable by everyone
30
Commons
* open areas for collaboration in an Agile work environment
* all team members should be able to see each other be no more than 33 ft apart
31
Community Values
* five values shared by team and stakeholders
1. respect for one another
* transparent communication
* freedom to be creative
2. respect for time
3. respect for end user
4. respect for the code and the process
5. respect for the rules and the team charter
32
Cone of Uncertainty
* estimating uncertain work makes it much more difficult to provide an accurate or narrow estimate
* beginning of the project is very uncertain
* as more iterations and thus planning happens, the cone of uncertainty narrows and iteration/sprint backlog grooming becomes more accurate
33
Continuous Integration
* core practice in XP that ensures new code integrates with existing code to avoid major problems in the future
* early warning about incompatible code and easier to fix smaller chunks of code
* easier to reverse code to last known good state
* disadvantage is the set-up time is lengthy, requires a dedicated server, and builing a suite of automated tests takes time
* incorporation of new and changed code into the repository
1. source code control system: version control
2. build tools: compile the code
3. test tools: unit test to ensure functionality
4. scheduler or trigger: builds are launched on schedule or conditions
5. notifications: email or IM reporting on results of the build
34
Convergent Collaboration
* participating decision making models like collective agreements and conversations about what the team is doing
35
Cross-Functional Team Members
* generalizing specialists -- knowledgeable in more than one area
* self-organizing
* assign work based on their own strengths and weaknesses
* work on one project at a time
* trying to make product
* in the shortest amount of time
* of the highest quality
* without external dependencies
* responsbile for
* sharing in daily stand-up
* sprint review
* participating in sprint retrospective
* writing tests
36
Crystal Clear Method
crystal method for team of 1-4 people
37
Crystal Methods
family of methods designed to scale and provide a methodology rigor based on the number of people involved in the project; emphasizes frequent delivery, reflective improvement, close or osmotic communication, personal safety, easy access to expert users, and automated testing
38
Crystal Orange Method
crystal method for team of 20-40 people
39
Crystal Red Method
crystal method for team of 5-100 people but with large budget and life
40
Crystal Yellow Method
crystal method for team of 6-20 people
41
Cumulative Flow Diagram
stacked area graphs that show features that are remaining, in progress, and completed
42
Cumulative Flow Diagram
chart that displays feature backlog, work-in-progress, and completed features
43
Customer Negotiation
five strategies for negotiating problems with customers
* accept (do nothing)
* avoid (create a work-around)
* ameliorate (reduce the impact)
* cover (make it invisible to the user)
* resolve (eliminate it)
44
Customer Tests
* core component of XP
45
Customers
* determine what success looks like in the project
* sometimes bring politics into the project
* team needs to use influencing, negotiation, and compromising to ensure business value items are top priority
46
Cycle Time
* time required to process an item
* measured from the moment the task is started to the moment it is completed
* used to measure bottlenecks and delays
* formula for cycle time is WIP / throughput
* if a team's throughput (velocity) in a ten day iteration is 27 points, and the WIP is 18 points
* 18 / 27 = .66 of an iteration for cycle time
* .66 of a ten day iteration is 6.6 days
47
Daily Standup Meeting
* only the development team and scrum master participate
* product owner can attend but cannot comment
* team micro-commits to each other and uncovers problems on a daily basis
* no longer than 15 minutes and at the same time and same place everday
* no side conversations
* solve problems offline
* answers
* what was completed since the last standup
* what is planned between now and the next standup
* what are the impediments
48
DEEP
* qualities of a product backlog which include
* detailed
* estimate-able
* emergent
* prioritized
49
Defect Cycle Time
* amount of time between you discover a defect and when it is resolved
* longer it takes to resolve, the more expensive the defect is
50
Definable Work
* characterized by clear procedures that have proved successful on similar projects in the past; ex: cars, electrical appliances, and homes
51
Defined Processes
* process works the same way the exact same time
* given the same inputs, a defined process should produce the same output every time
52
Dispatching Communication Model
* two-way communication that is top-down
* communication between manager and employee
53
DMAIC
* phases within the methodology for Six Sigma
* define: project is defined, business value is identified, project charter is developed
* measure: data is collected, measurements are defined, defects are defined, benchmarks are defined
* analyze: find root cause of defects, 5 Whys, fishbone diagram
* improve: eradicate defects and improve process
* control: validate benefits of the improvements, transfer project to owner, close out project
54
Dot-Voting (Multi-Voting)
* stakeholders get a predetermined number or dots to vote on the features they think are most important
* can color code them for prioritizing and weighting stakeholders
* risks
* new features can't be considered once voting begins
* similar options are penalized
* people might follow the crowd
55
Dreyfus Model of Adult Skill Acquisition
* novice: follow the rules and make analytical decision
* advanced beginner: follow rules but based on experience can better understand the rules
* competent: determine which rules are best for each situation
* proficient: actively choose the best strategy rather than simply relying on the rules
* expert: decision-making becomes intuitive
56
Dynamic Systems Development Method
* emphasis on constraint-driven delivery
* framework sets cost, quality, and time from the outset and then uses formal prioritization of scope to meet those constraints; focuses on the business need
* on-time delivery, collaboration, uncompromised quality, incremental builds with strong foundations
* iterative development
* continuous and clear communication
* demonstrated control by using appropriate techniques
57
Eight Characteristics of High-Performance Teams
1. self-organizing
2. empowered
3. believe they can solve any problem
4. committed to team success
5. own decisions and commitments
6. motivated by trust
7. consensus driven
8. participate in constructive disagreement
58
Empirical Processes
* no defined work that's created
* based on the project and what is happening
* more creative than defined processes
* reactive
59
* self-organizing Agile teams need
* clarity: understand they have permission to be creative and do the work
* ability: training if they need more technical knowledge
* authority (agency): team can make decisions
* safety: team won't have repercussions for trying new things and will be protected
* belief (confidence): confidence in abilities, system, process, and product
* interest: excited about the project
60
Engagement Culture
* reward people for solving problems and sharing the knowledge they gained from the process
61
DSDM Contracting
* creates a fixed schedule, cost, and quality approach but follows Agile framework
* takes best parts of RAD and waterfall and adapts them to Agile projects
62
Epic
* large user story that spans more than one iteration in Agile
* five or more related user stories are an epic
63
Escaped Defects
* defects reported by the customer that have escaped all software quality processes
* most expensive to fix
64
Exploratory Testing
* aims to discover issues and problems with behavior
* attempt to break the software
* NOT automated; tester is in charge
* in addition to scripted testing
65
eXtreme Programming (XP)
* goal: simplest thing that could work
* software development method based on frequent cycles team
* consists of coach, programmers, testers, and customer
* the team sits together in an informative workspace
* there's real customer involvement
* team works at a sustainable pace
* utilizes pair programming and test-first programming
* collective ownership of code
* incremental design
* ten-minute build
* continuous integration
66
Feature-Driven Development Method (Domain Object Modeling)
* developed to meet the needs of a large software development project
* order of work is to develop an overall model, build a feature list, plan by feature, design by feature, and finally build by feature
* each class of code is assigned to a single owner
* emphasis on configuration management
* domain object modeling: a technique used to understand the project problem description and to translate the requirements of that project into software components of a solution
* regular builds of product
* share visibility of progress
67
Features Chart
* burnup or burndown chart that shows how requirements grew over the project
68
Fist of Five
decision making technique in which voting is signaled by fist; closed fist is no support and five fingers up is full support; fewer than free fingers, the team member discusses the objections
69
Five Dysfunctions of a Team
1. absence of trust
2. fear of conflict
3. lack of commitment
4. avoidance of accountability
5. inattention to results
70
Five Whys
* root causes analysis technique that asks WHY five times
* problem is looked into deeper each time WHY is asked. Toyota developed this technique
71
Fixed-Price Work Packages
* individual work packages are estimated for cost and the price of the work remains constant
* vendor only gets that amount of money to complete that work package
* vendor assumes the cost of overruns
* new changes to scope are estimated as they come
72
Graduated Fixed Price Project
* if a vendor delivers on time, they are paid the hourly rate
* if a vendor delivers early, they get a bump in the hourly rate
* if a vendor delivers late, they get a reduced hourly rate
* prevents sandbagging
* buyer and seller get to share in success
73
Green Zone
* environment that encourages individuals to
* take responsibility
* respond non-defensively
* welcome feedback
* build mutual success
* use persuasion to implement their ideas
* be firm but not rigid
* think about both short-term and long-term goals
* approach conflict neutrally
* speak calmly and directly
74
Grooming the Backlog
* backlog refinement/prioritization of backlog items (user stories) by the product owner representative of the stakeholder
* entire project team might participate but the product owner is officially in charge of the backlog
* consider the risks introduced each time
75
Gulf of Evaluation
* difference between is said and what is understood
* particularly an issue with intangible projects such as website development
* a firm DOD helps prevent this
* frequent checkpoints and reviews provide opportunities to build consensus between project team and project stakeholders
76
Hallway Testing
quick usability test of the interface being developed; purpose is to make sure that users perceive it as intended by the developers, and to identify any obstacles that arise during its use; test subjects are people not involved with project
77
High-Bandwidth Communication
face-to-face communication that also includes non-verbal communication
78
Highsmith Decision Spectrum
* spectrum from in favor of an idea to mixed feelings to not in favor but will commit to veto
79
Ideal Time
* in estimating, the time it would take to complete a user story if there were no interruptions
80
Increment
* fully-developed, working, potentially shippable product
* each increment is ready to be released once there's enough aggregated value
81
Indifferent Quality
* Kano category of customer preference
* customers are indifferent to quality feature
82
Information Radiator
* also known as visual controls
* ideally low-tech high-touch
* highly visible and accessible display of information about your project
* should include
* features delivered vs. remaining
* who is working on what
* current iteration features
* velocity
* defect measurements
* threats and issues for projects
* burnup and burndown charts
* story maps
83
Information Refrigerator
information that is not transparent or useful to the team and stakeholders
84
Inverted Triangle Model
In the triple constraints of scope, time, and cost, what is variable and what is fixed? In predictive, scope is often the most fixed and resistant to change and in adaptive/agile, time and cost are fixed and scope is the moving target
85
INVEST User Stories
* independent: prioritized in any order
* negotiable: team can discuss the user story with the product owner and make trade-offs based on cost and function
* valuable: must have obvious value
* estimatable: can be estimated for effort
* small: 4 to 40 hours of work
* testable: story results must be testable
86
Iteration H
* hardening
* wrap-up sprint during which
* code is stabilized
* product is documented
* final product is compiled
* testing is finished
87
Iteration Zero
* initial iteration during which the stage is set for development
* typically there are no deliverabels to the customer during iteration zero
88
Iterative Life Cycle
early planning of high-level scope sufficient to allow for preliminary estimate of time and cost; scope is developed a little more with each iteration \* the complete concept is built in successive levels of detail to create the end result \* go through iterations, repeated phases, to get to the final product \* example: the first iteration would focus on planning a prototype of the entire website and after the skeleton is built each iteration would be planned to add more detail until the site is complete and fully functioning
89
Just Because Documentation
documentation required either because it's a law or regulation or an organization has not fully adopted Agile and it's an organizational rule
90
Just in Time (JIT)
suppliers deliver resources just before they are needed, decreasing inventory down to nearly zero; JIT requires organizations meet a high level of quality in their practices
91
Kaizen (Continuous Improvement )
continuously looking for ways to improve the quality of work, processes, and results
92
Kanban Board
* pull-system for work
* not time-boxed
* board that shows requirements/user stories that are yet to be done, in progress, in testing, or complete
* WIP is the Work in Progressasks are of similar size
93
Kanban Method
system for scheduling inventory control and replenishment; does not prescribe the use of timeboxed iterations but emphasizes pulling single items through the process continuously and limiting WIP to optimize flow and continuous delivery; utilizes kanban board and information radiator
94
Kano Analysis
* five categories of customer preferences
* must-be quality
* one-dimensional quality
* attractive quality
* indifferent quality
* reverse quality
* delighters: met the quality and excited
* satisfiers: expect it to perform and unhappy if it doesn't
* dissatisfiers: if it's something that is a must-be and doesn't work, very unhappy
* indifferent: doesn't care one way or another
95
Lead Time
* total time it takes to deliver an item, from the time it is added to the board to the time it is completed
* can help identify and diagnose problems
96
Lean Management
uses product backlog and next/resource person takes on the work; remove waste of time, effort, and resources; agile is a derivative of this approach, which encompasses both human and physical resources
97
Level 1 Conflict
problem to solve -- everyday conflict; people have different opinions or there might be a misunderstanding; team members will likely feel anxious about the conflict; team aims to determine what's awry and how to fix it; information is shared clearly; uncomfortable but constructive
98
Level 2 Conflict
disagreement -- self-protection is as important as solving the problem; team members distance themselves from one and another; not hostile but wary
99
Level 3 Conflict
contest -- aim is to win; compounding effect as prior conflicts remain unresolved; often this is when factions emerge and power politics come into play; problems and people become synonymous and blaming flourishes; example: "he always forgets to code"
100
Level 4 Conflict
crusade -- team members believe other s are incapable of changing and resolving situation is not enough; identifying with faction overshadows identifying with the team; language becomes rife with ideology and principles; attitude is righteous and punitive
101
Level 5 Conflict
world war -- not enough to be the one who wins; other must lose; must be avoided at all costs; only way to resolve the situation is remove team members as there is no hope for a constructive outcome
102
Levels of Listening
1. internal listening: words are heard but not listening beyond yourself
2. focused listening: listening to the speaker's perspective and empathizing; looking for emotional indicators such as word choice, tone, and facial expressions
3. global listening: look for even subtle cues of the speaker to get a fuller picture
103
Little’s Law
* duration of a queue is proportional to its size
* the more items you have in your WIP, the longer it takes to get them done
* limiting the items makes the team work faster
104
Low-Tech/High-Touch Tools
* Agile teams should prefer low-tech tools like whiteboards and posters over complicated software
* learning software does not add business value
* scheduling and stakeholders might require technology for accuracy and transparency
105
Meeting Facilitation
* agenda to make sure the meeting is effective
* establish ground rules
* hold people accountable during the meeting
* promote participation
* determine meeting duration beforehand and stick to it
106
Metaphors
way to explain design and communicate the software to customers
107
Minimum Viable Product (MVP)
* product with only the essential features delivered to early adopters to receive feedback
* product gains customer acceptance with the least amount of work possible
* minimal marketable feature
* barebones essential of a product
108
MoSCoW Analysis
* a method for helping stakeholders understand the importance of each requirement
* stands for
* Must have
* Should have
* Could have
* Would like to have
109
Must-Be Quality
* Kano category of customer preference
* features that are required for product to work
* customers ignore these when quality is achieved but are dissatisfied when not
110
One-Dimensional Quality
* Kano category of customer preference
* spoken attributes that are promised
111
Pair Programming
in XP, one person codes while another person watches and thinks about the code being developed; catches mistakes quickly
112
Personas
* biographical sketches of key stakeholders and how they will use the product
* show tangible and actionable outcomes
113
Planning Game
* planning game is a planning meeting held by the development team and stakeholders
* two sessions: release planning and iteration planning
* customers and all developers in the team must participate
* similar to the planning meeting of Scrum
* customer outlines functionality and developers estimate the difficulty to build
* release planning and the iteration planning of the planning game include three phases, namely exploration, commitment and guidance.
114
Planning with Poker
* cards that have the Fibonacci sequence
* participants show their cards for each user story to score it
* estimates based on size, not hours
115
Principle of Agile Planning
* planning at a high-level, product-level, user-story-level, and then individual tasks
* engage the team and customer in planning
* tailor processes and only do processes to the necessary depth
* utilize estimate ranges
* base forecasts on completion rates
* factor in diversions and outside work
116
Prioritization Scheme
* product owner and team agree about how the work will be prioritized moving forward in the project
117
Product Backlog
product scope in an adaptive environment; always prioritized before the current sprint
118
Product Box
* visualization exercise that helps recognize most important top three features of product that add value
119
Product Breakdown
take a product and break it down to each component and analyze what each component does
120
Product Owner
* represent the business
* works with team daily by providing feedback and setting direction
* only person who can cancel a sprint
* responsible for
* prodcut vision
* product roadmap
* guiding the direction of the product
* prioritizing the backlog based on business value
* grooming the product backlog along with input from development team
* release planning so ROI is achieved as soon as possible
* iteration planning along with development team
121
Product Reviews/Demonstrations
team demonstrates the working product once a feature is complete; product owner sees the demonstration and accepts or rejects the product
122
Product Roadmap
* visualization of product features and when they will be released
* outlines the vision, direction, priorities, and progress of a product over time
* helps to check for risk
* first stab at the product backlog
* also shows KPI
* product owner creates and owns the product roadmap
123
Product Vision
* first step in leading an agile project
* written in present-tense
* outlines how the product will serve the customer’s needs and aligns with organizational strategy
* serves as the "guiding light" that the teams constantly refers, consults and steers towards.
* product owner creates the project vision in alignment with company strategy
* validated and revised after it is written based on stakeholder input
124
Productivity vs. Efficiency
* productivity is how much work gets done
* efficiency is how quickly work gets done without any errors
125
Progressive Elaboration
* as more information becomes available, more planning can hapen
* continues steadily in small increments until plans are very specific
* progressive elaboration happens in
* plan
* estimates
* risk assessments
* requirements definiton
126
Prune the Product Tree
* collaborative game for defining what success looks like
* starts with a drawing of a tree
* trunk has sticky notes with what we already know or has been built
* participants add new features to the branches of the tree with sticky notes
* higher priority items are moved closer to the trunk
127
Qualities of an Agile Leader
* coordinates work instead of directing it
* give transparency through visualization, particuarly with an information radiator
* encourage experimentation by creating a safe environment
* share knowledge through collaboration and encourage team members to share information
128
Quality
* totality of entity that will bear on its ability to satisfy stated and implied needs
* understand good requirements
* conform to those requirements
* product has to be fit for use for the customer
129
Red Zone
* creating an environment in which individuals
* blame others
* respond defensively
* only think of short-term goals
* don't listen effectively
* show disapproval and content
* feel victimized
* must win
* shame, blame, and accuse
* think in binary terms -- either yes or no
130
Red-Green-Clean
* XP and test-driven development practice
* also known as red-green-clean
* write test for code first
* red: code will immediately fail at first because it is not fully developed
* green: eventually code will pass the test
* clean: refactoring
131
Refactoring
* adjust working code to improve functionality and conservation
* adhere to standards
* improve ease of future support
* core value of Agile generally but in particular XP
132
Regression Testing
software testing to confirm that a recent program or code change has not adversely affected existing features
133
Regulations in Agile
* regulations and laws are requirements
* one instance for documentation where just because is utilized
* not following regulations is a risk
134
Relative Prioritization and Ranking
* priority of features
* simplest features from most to least important
* determination made to meet budget and schedule
* changes may prompt reprioritization of backlog
* changes may prompt some priorities from the list
135
Relative Sizing for Story Points
* relative sizing is a form of analagous estimating
* story points are a unit of measure
* difficult to make an absolute estimate for work you have done before so stories are measured against each other in relative sizing
136
Release
publishing of the software; not necessarily at the end of the iteration; a release planning meeting is held before each release with scrum team
137
Release Planning
* release timing for specific product functionality
* priorities assigned to the product features from most important to least important
* release planning is owned by the product owner
* inputs to release planning
* results from previous iterations
* feedback from stakeholders about the product, market conditions, and deadlines
* defects and variations
* development and architecture information
* velocity
* organizational and personal calendars
* input from other teams and SMEs
138
Release Planning Meeting
* meeting held before each release with all stakeholders
* discuss how to get to the release; also includes planning for future releases
* led by product owner
* format
* discuss product vision and roadmap
* remind team of larger picture
* give status on development, state of architecture, and results of previous iterations
* discuss new information
* give the release name and theme
* discuss velocity
* discuss release schedule
* review milestones
* issues and concerns
* review stories and items from the backlog
* determine sizing values
* slice user stories as needed
139
Remember the Future
* defines what success looks like to stakeholders
* collaboration game during which stakeholders pretend to look back at the project years down the road and spend 20 minutes writing a report about how it went
* includes what was created
* ideas generated are written on sticky notes and clustered in affinity diagram
140
Requirements Prioritization Model
* every feature is voted on a scale of 1 to 9 for
* benefit to the organization; cost to benefits ratio
* penalty of not doing the project
* cost
* risk
* other considerations for model
* business value (ALWAYS the most important factor)
* expense versus ROI
* prioritizing risk requirements first
* difficulty of implementation
* success factors -- what features have the highest probability of success
* regulatory compliance
* relationship to other requirements; are requirements linked
* stakeholder consensus on requirements
* urgency
141
Response Time (Flow-Based Agile)
time that an item waits until work starts
142
Responsibilities of the Servant Leader
* primary roles
* shield the team from interruptions
* removes impediments to team
* communicate and re-communicate project vision
* lead through service to the team, by focusing on understanding and addressing the needs and development of team members in order to enable the highest possible team performance
* also
* builds communication within the team and across the organization
* educates stakeholders about agile
* celebrates with team and give positive feedback
* mentors and encourages
* facilitates collaboration because teams choose with whom they want to work
* performs technical project management activities like quantitative risk analysis
143
Reverse Quality
* Kano category of customer preference
* some customers will love the feature but some will hate it
144
Risk in Agile
* anything that threatens the project's goal of creating value for the organization
* generally considered to be negative in Agile
* risk identification is iterative
* risks are recorded in a risk log
145
Risk-Based Spike
* a short effort early in the project to reduce or mitigate risk
* good for new technology and reinforces the idea of fail early and fail often
146
Rolling Wave Planning
* an iterative planning technique in which the work to be accomplished in the near term is planned in detail, while the work in the future is planned at a higher level
147
Sailboat/Speedboat Game
* collaborative game for defining what success looks like
* stakeholders imagine a sailboat or speedboat and then discuss
* winds are what are the pushing the sailboat (project)
* anchors are what are holding the sailboat (project) back
* direction is the goal of the project
* rocks are impediments
148
Sapir-Whorf Hypotheses
understanding the language you speak affects how you think; speaking different languages can cause miscommunication
149
Screen Design
shows the interaction between the user and product and helps get the product owner and development team on the same page; can help prevent scope creep
150
Scrum
* single-team process framework to manage product development
* uses an iterative approach to deliver a working product
* runs on timeboxes of one month or less with consistent durations called springs
* each sprint results in a potentially (but not necessarily) increment of a product
151
Scrum Artifacts
* product backlog
* sprint backlog
* increments
152
Scrum Master
* servant leader on Scrum teams
* responsible for making sure team has what they need to complete project and removing impediments
* takes care of project administrative tasks
* maintains information hubs
* leads daily stand-up meeting
153
Scrum of Scrums (SoS)
technique used when two or more Scrum teams each need to coordinate their work instead of work on one large Scrum team; a representative from each team meet daily to ensure coordination of work
154
Scrum Pillars and Values
* transparency: a common understanding on definition of done
* inspection: reviewing project to determine the completeness and finding the root cause of variances
* adaptation: make adjustments to scrum process to mitigate problems or negative trends
155
Seven Characteristics of Servant Leadership
* promoting self-awareness
* listening
* serving those on the team
* helping people grow
* coaching not controlling
* promoting safety, respect, and trust
* promoting the energy and intelligence of others
156
Seven Lean Core Concepts
1. eliminate waste
2. empower the team
3. deliver fast
4. optimize the whole
5. build quality in
6. defer decisions
7. amplify learning
157
Shu-Ha-Ri
* Shu: start by following the rules
* Ha: once the team has mastered the guidelines they can move away from them and work intuitively
* Ri: the team reaches full master and can transcend the rules
158
Simplicity
* art of maximizing the amount of work not done
* tenth point in the twelve principle of agile and essential to the agile mindset
* mitigates risk
* core practice in XP
159
Six Rules of Interdependence
1. ROI is the goal and delivered quickly
2. deliver reliable results and keep errors out of the hands of the customers
3. expect uncertainty
4. allow experimentation and creativity
5. boost performance by being a servant leader
6. improve effectiveness and reliability by learning from mistaktes
160
Sizing T-Shirts
* user stories are assigned t-shirt sizes to keep the sizes relative to each other
161
Slicing
* decomposing or cutting down a user story
162
Spend the Monopoly Money
* stakeholders spend fake money to purchase the requirements or features they think are most important
163
Sprint
* anywhere from 1 to 4 weeks
* sprint planning
* sprint (design-test-develop-test-integrate-test)
* sprint review
* sprint retrospective
164
Sprint Backlog
* subset of the product backlog
* serves as the goal for the current iteration
* sprint backlog is updated and refined by the development team
* once the sprint backlog is set, it cannot be changed
165
Sprint Planning Meeting
* meeting for and facilitated by the delivery team
* confirm goal for the current iteration
* discuss user stories in the backlog and select stories for current iteration
* define the acceptance criteria
* break user stories into tasks
* estimate the tasks
166
Sprint Retrospective
* team meeting that usually occurs after each sprint or iteration;\
* single most important practice because it allows team to learn about, improve, and adapt its process
* analyze qualitative data such as people's feedback and quantitative data to find root causes, design countermeasures, and develop action plans to remove impediments
167
Sprint Review
* a meeting that typically lasts about four hours at the end of a four week sprint
* includes development team, scrum master, product owner and possibly but not usually other stakeholders
* development team demos product
* deliverables are presented and inspected if they are 100% complete
* feedback is collected and change requests are documented
168
Story Points
* scores the difficulty of the tasks needed to complete a user story during a sprint
* also takes risk of task into account
* team owns the definition of story points
169
Story Slicing
breaking large user story into chunks so it can be done over multiple iterations; better for planning
170
Storyboarding
in collect requirements, draw how the requirement works in the solution
171
Swarming
* similar to crashing in a predictive approach
* multiple team members work together toward a solution for one item to finish it on time
172
T-Shaped People
generalizing specialists who have a focus specialty but also a breadth of experience across multiple skills; agile teams work to develop such characteristics through intense collaboration
173
Tabaka’s Model
model originated in Japan to describe a team with values that include self-organization, empowered to make decisions, belief in vision and success, a committed team, trust, participatory decision making, consensus-driven, and construction disagreement
174
Task Board
* white board or virtual white board that shows all the steps a requirement or feature needs to go through to be completed
175
Tasks
smaller components of work that make up an activity; smallest element of decomposition in Agile
176
Team Facilitator
* generic Agile project master
* servant leader
* get team what they need to complete the project
* remove impediments
* helps the product owner communicate priorities to team and external stakeholders
* helps guide the Agile processes
* helps product owner groom the backlog
* facilitates meetings
* follows up on issues, such as personnel problems or technology problems
177
Technical Debt
* backlog of work caused by lack of regular clean-up maintenance and standardization
* refactoring solves technical debt and makes it easier to support in the future
* refactoring should be included in estimates
178
Test-Driven Development
* core practice in XP
* automated tests are written before writing or creating the product
* helps people design and mistake-proof the product
* initial tests will fail because the code has not yet been fully developed
* refactoring is the final step in cleaning up code
179
Three Cs of User Stories
* card: user story captured on an index card
* conversation: discussion about objectives of user story between customers, users, developers, and testers
* confirmation: agreement the objectives of the conversation have been reached and the story has been implemented correctly
180
Three Pillars of Scrum
transparency (don't hide information); inspection (inspect frequently and make results visible to everyone); adaptation (adapt and overcome; make adjustments ASAP)
181
Timeboxing
* fixed duration of time in which a set number of activities are worked on
* timeboxed sprints identify number of items from the product backlog that will be worked on and any that are not finished go back into the product backlog
182
Unit Testing
in XP, the smallest testable portion of code; automated process for testing; isolated testing for validity; developers and customers collaborate during unit testing
183
Usability Testing
* exploratory test which uses a test subject to understand the usability of software
* tests how the product will work in a real environment and how easy is the system to use
* what improvements need to be made for ease of use?
184
Use Case Diagram
defines discrete system behavior of value to a particular actor (user role). The best use cases are those written in active voice, in present tense, in terms of user action/system response ( the user does this; the system responds by doing that ), and unambiguously using the terms defined in an accompanying glossary or domain model
185
User Stories
* small chunk of business functionality
* defined sometimes as 1 to 3 days of work and sometimes as 40 hours of work
* define the
* role: who benefits from the feature
* goal: what the stakeholders aim to accomplish
* motivation: benefit to the stakeholder
* basic formumla
* as a , I want so that I can
* story formats
* given: scenario for the story
* when: what are the conditions under which the actions take place
* then: the result of the action
186
User-Centered Interaction Design
* goal is to know how users will interact with and become frustrated with product
* iterative design process in which designers focus on the users and their needs in each phase of the design process
* design teams involve users throughout the design process via a variety of research and design techniques to create highly usable and accessible products for them
187
Value Analysis (Value Engineering)
finding a less costly way to do the same work while maintaining scope
188
Value-Based Decomposition
prioritize requirements based on value; elicit requirements, then the product owner groups requirements of like features; break down the features and rank the requirements, and finally prioritize them into development
189
Value-Based Decomposition
* type of value-based analysis in which requirements are broken down and grouped by value
190
Velocity
* rate at which deliverables are being produced, validated, and accepted
* how many story points on average are being completed in an iteration
* allows for forecasting and assessing accuracy of user story sizing
* know how to calculate how many weeks are left (remaining story points / story points per iteration) then multiple this number by the weeks in an iteration
191
Verification and Validation in XP
checkpoints for gaining consensus on definition of done
1. pair programming
2. unit testing: confirm what's been written will compile and integrate
3. customer collaboration: talk to customers every day
4. standup meetings
5. acceptance testing: once code is compiled and get sign-off on what was created
6. iteration demonstrations
7. product release
192
Visioning
* high-level planning prior to planning the first release
* map out the overall effort of the project
* product owner, sponsor, and key team members are present
* outputs
* coarse-grained relative estimates for user stories
* goals of the releases
* release dates
193
War Room
* locatioin for team members in the same space that has both commons and caves
* information radiators and other visualizations of progress
* tools for communication like white boards
194
Wideband Delphi
rounds of anonymous estimates; helps to build consensus; prevents bandwagon effect and groupthink
195
Wideband Delphi
* rounds of anonymous estimates usually done through surveys
* helps avoid HIPPO -- the highest paid person's opinion -- and group think
196
Wireframe
* quick diagram showing the user interaction with the solution
* low-fidelity prototyping
197
Work in Progress (WIP)
* work is limited because
* work in progress represents risk
* WIP can hide bottlenecks because the team can look busy working but might actually be struggling
* WIP requires confidence in team
* WIP delivers not value until the work is completed
198
XP Teams
* generalizing specialists
* co-located
* coach (mentor/guide/facilitator): similar to the scrum master
* customer: provides requirements priorities and direction for the project; similar to the product owner
* programmer
* tester: defines and writes the acceptance tests
199
Grooming for Risk
* stories are ranked based on business value and risk level
* ROI for the project can be broken down per item and then business representatives can assign ROI to each item in the backlog
* EMV of risk in a probability impact matrix can also help rank risk based on monetary value
200
Issues
* risk events that have already happened
201
Throughput
* amount of work that can be through a system in a given amount of time, such as the amount of work a team can get done in an iteration
202
Impediment Board
* visual tool that allows teams to track risk over a project
203
Pre-Mortems
* facilitated team sessions used to identify possible failure points for the project so they can minimize the chances of failures happening and mitigate the damage if it does
* process typically consists of
* imagining the failure
* generating reasons for the failure
* consolidating the list
* revisiting the plan
204
Risk Burndown Chart
* used for planning, managing and controlling risk
* allow stakeholders to easily see a risk profile on a project
