Flashcards in POM E3 Deck (29):
Product Backlog :
List of requirements for the whole product
List of requirements and tasks for one iteration (“Sprint”)
Potentially Shippable Product Increment:
Release to the Product Owner that
contains all results of the current Sprint
Scrum Meetings, contains :
#Project Kickoff Meeting (Start of the Project): Create and prioritize Product Backlog
#Sprint Planning Meeting (Start of each Sprint): Create Sprint Backlog
# Daily Scrum Meeting (Every Morning,15min): Standup meeting to share status,
impediments and promises
#Sprint Review Meeting (End of each Sprint): Demonstration of realized backlog items
to the Product Owner (and other stakeholders)
Scrum-Team, Product owner ;
Defines the product
Responsible for results
Scrum-Team, Scrum Master;
Responsible for the process
Scrum-Team, Development team;
Self-organizing and cross-functional
Realizes the product increment
What is a Sprint?
# Typically 2-4 weeks long
# Starts with Sprint Planning Meeting (Create the Sprint Backlog, Development Team and Product Owner select the items together)
# Ends with Sprint Review Meeting (product increment, Demo of the application during the meeting, Product Owner gives feedback)
The development team during a sprint
# Works on the items in the Sprint Backlog
# Uses e.g. a Task Board to visualize the status of these items
# The Scrum Master visualizes the progress, e.g. in a Burn Down Chart
(Items, TODO, in progress, in review, Done)
• Collection of items (e.g. user stories, scenarios, etc.) prioritized by the Product
• changeable and reprioritizeable
• Created before the project starts and based on kickoff meeting
Priorities, and by whom is it done?
Prio 1 = Critical
(released in product increment 1)
Prio 2 = Major
can be realised after first release)
Prio 3 = Minor
(if there is time we'll do it)
Prio 4 = Trivial
(may be realised)
Prioritization is done by the Product Owner
Two ways to control Software Development
- Organizational Maturity
Empirical Process Control Model, and when to apply it
# Empirical process: An imperfectly defined process, not all pieces of work are completely understood
# Deviations, errors and failures are seen as opportunities that need to be investigated (the unexpected is expected)
# Control and risk management is exercised through frequent inspection
The EPCM pre conditions:
# Change is frequent and cannot be ignored
# Change of requirements, change of technology, change in the organization, people
Includes a sentence that the describes what the user does or needs.
US is ofter written on a card.
Properties of a good User Story: INVEST
Independent (avoid overlapping)
Negotiable (a basis for discussion between dev. team and product owner)
Valuable and Vertical (features not layers are planned and developed)
Estimable (basis of the project plan is the product backlog)
What are Scenarios ?
A scenario represents a concrete sequence of
interactions between one or more actors and the system.
What is the relation between User Stories, Use Cases and Scenarios ?
#Scenarios are typically created during Analysis
#Use Cases and Scenarios typically cover a larger scope and are more
formal than User Stories
# User Stories are usually created during requirements elicitation
What is a task ?
Smallest unit of work.
#A software project has a specific duration, schedule,
consumes resources and produces work products
What are Management activities to complete a software
Tasks, activities, project functions
What is Software Project Management Plan (SPMP) ?
#The controlling planning document for a software
#Specifies the technical and managerial approaches
to develop the software product
#May be part of the agreement
What is Project Agreement and what does it include ?
A document written for a client that
• the scope, duration, cost and deliverables for the project
• the exact items, quantities, delivery dates, delivery location
What is IEEE Std 1058 and what does it ?
The IEEE 1058 standard describes the structure of a
software project management plan.
Specifies the format and contents of software project
management plans but not the procedure
Hierarchical decomposition of the project into
activities and tasks. (The aggregation of all the work
to be performed in a project. )
Two major philosophies for Creating Work Breakdown Structures
Approaches to Develop a WBS
#Product component approach
• Structure the work around the work products
• Example: Design documents, manuals, delivered system
• Structure the work around development activities
• Example: Analysis, design, implementation, integration
#Geographical area approach
• Structure the work based on the geographical location
• Example: Munich team, off-shore team
• Structure the work based on the organization
• Example: Line organization with R&D, predevelopment,
product development, marketing, sales.
• Structure the work as a to-do list
• Example: Product backlog, sprint backlog.
When to use what Approach
#The teams are distributed over the continent:
• Geographical area approach
# The teams consist of experienced developers:
• Product component or agile approach
#The project consists mostly of beginners or has an
inexperienced project manager:
• Functional approach
#The project is a continuation of a previously successful
project, there are no changes in the requirements and no
new technology enablers:
• Organizational approach
Displaying Work Breakdown Structures (3 formats)
• Effectively portrays an overview of your project and the
hierarchical relationships of different activities and tasks
• Sub-activities and tasks are indented below activities
• Backlog: Outline format without indentation.
• The bubble in the center represents your project
• Lines from the center bubble lead to activities
• Lines from activities lead to tasks.