POM E3 Flashcards
Product Backlog :
List of requirements for the whole product
Sprint Backlog:
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;
Resolves impediments
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)
Product backlog
• Collection of items (e.g. user stories, scenarios, etc.) prioritized by the Product
Owner
• 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
- Agility
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 change too.
User stories
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)
Small
Testable