PSM 1 Flashcards
Agile
Agile is a certain approach to development. Agile is referred as an Adaptive approach, as opposed to traditional Predictive approach.
In an Adaptive approach, we move from one increment to another.
Scrum is an Agile framework/methodology
Agile
Agile is a certain approach to development. Agile is referred as an Adaptive approach, as opposed to traditional Predictive approach.
In an Adaptive approach, we move from one increment to another.
Scrum is an Agile framework/methodology
Incremental delivery & Iterative development
Incremental delivery: We deliver the product in multiple steps. We can see increments as different versions.
Iterative development: We repeat the development process for each increment.
Incremental delivery & Iterative development
Incremental delivery: We deliver the product in multiple steps. We can see increments as different versions.
Iterative development: We repeat the development process for each increment.
Product Backlog
- A list of items that are sorted based on their business value ( = importance).
- Scrum doesn’t tell how to sort items. Calculating business values depends on the project. Think about business values as Return on Investment.
- The Product Owner is responsible for the Product Backlog.
- The Product Backlog is not entirely created at the beginning of the project but will be updated after each Sprints.
- The Product Backlog is a dynamic and evolving structure.
Product Backlog
- A list of items that are sorted based on their business value ( = importance).
- Scrum doesn’t tell how to sort items. Calculating business values depends on the project. Think about business values as Return on Investment.
- The Product Owner is responsible for the Product Backlog.
- The Product Backlog is not entirely created at the beginning of the project but will be updated after each Sprints.
- The Product Backlog is a dynamic and evolving structure.
Product Backlog - Items
Items in the Product Backlog should have 2 characteristic:
- Non-technical: we should be able to communicate with customers.
- Independent: items should be independant of each other, otherwise we won’t be able to sort them only based on their business value.
Product Backlog - Items
Items in the Product Backlog should have 2 characteristic:
- Non-technical: we should be able to communicate with customers.
- Independent: items should be independant of each other, otherwise we won’t be able to sort them only based on their business value.
User Story
To make items clear enough, they should be written as User Stories:
As a …, I want to … [, so that …]
User stories are about features.
User Story
To make items clear enough, they should be written as User Stories:
As a …, I want to … [, so that …]
User stories are about features.
Non-Functional Features
Non-Functional Features are features such as security, serformance, maintainability, scalability, …
Can be either:
- applied to all items in the Product Backlog (more common)
- created as items in the Product Backlog
Non-Functional Features
Non-Functional Features are features such as security, serformance, maintainability, scalability, …
Can be either:
- applied to all items in the Product Backlog (more common)
- created as items in the Product Backlog
Sprints
- “Sprint” is the Scrum term for “iteration”.
- Sprints are a timeframe within a project. In Scrum, Sprints have a duration of 1 month maximum.
- At each Sprints, we take care of several items from the top of the Product Backlog.
- Sprints should have the same length through the duration of the project. You can however decide to change the duration of the Sprints during the project.
- The purpose of a Sprint is to create a piece of working software that we can show to the customer and receive feedback.
- The output of a Spring is called an Increment.
- We don’t have to release all Increments, but all of them should be potentially releasable. A realease usually happens every few Sprints.
Sprints
- “Sprint” is the Scrum term for “iteration”.
- Sprints are a timeframe within a project. In Scrum, Sprints have a duration of 1 month maximum.
- At each Sprints, we take care of several items from the top of the Product Backlog.
- Sprints should have the same length through the duration of the project. You can however decide to change the duration of the Sprints during the project.
- The purpose of a Sprint is to create a piece of working software that we can show to the customer and receive feedback.
- The output of a Spring is called an Increment.
- We don’t have to release all Increments, but all of them should be potentially releasable. A realease usually happens every few Sprints.
Sprint Planning
- During the Sprint Planning event, we create the Sprint Backlog and the Sprint Goal.
- The Development Team is responsible for the Sprint Backlog.
- The entire Scrum Team is responsible for the Sprint Goal.
- Typically the Sprint Planning event lasts 8 hours for a one-month Sprint.
Sprint Planning
- During the Sprint Planning event, we create the Sprint Backlog and the Sprint Goal.
- The Development Team is responsible for the Sprint Backlog.
- The entire Scrum Team is responsible for the Sprint Goal.
- Typically the Sprint Planning event lasts 8 hours for a one-month Sprint.
Sprint Backlog
We move items from the Product Backlog to the Sprint Backlog at the beginning of each Sprint.
The Development Team decides which items are moved from the Product Backlog to the Sprint Backlog.
Sprint Backlog
We move items from the Product Backlog to the Sprint Backlog at the beginning of each Sprint.
The Development Team decides which items are moved from the Product Backlog to the Sprint Backlog.
Story Points
Items are sometimes attributed “Story Points” to asses the relative effort needed to process them (e.g. to weight items). We can also use “Man Hours” or “Man Days”.
At the end of each Sprint, we can asses how many units/story points have been completed. We only consider items that have been fully completed.
Story Points
Items are sometimes attributed “Story Points” to asses the relative effort needed to process them (e.g. to weight items). We can also use “Man Hours” or “Man Days”.
At the end of each Sprint, we can asses how many units/story points have been completed. We only consider items that have been fully completed.
Velocity
The average of units completed per Sprint is called Velocity. The Velocity is calculated by the Development Team.
The Development Team is free to pick up how many items they want (unit sum of those items can be lower or higher than the Velocity). The Development Team owns the Sprint Backlog.
The Scrum Team
The Scrum Master is responsible for making sure the team uses the Scum framework properly.
The Scrum Master with the Product Owner and the Development Team (3 to 9 team members) together form the Scrum Team.
Scrum Teams are self-organizing and cross-functional.
The Scrum Team
The Scrum Master is responsible for making sure the team uses the Scum framework properly.
The Scrum Master with the Product Owner and the Development Team (3 to 9 team members) together form the Scrum Team.
Scrum Teams are self-organizing and cross-functional.
Scaled Scrum
If we need more team members, we need to add more team (rather than a bigger team) and to use Scaled Scrum.
In Scaled Scrum there should be only one person responsible for the business values, so only one Product Owner and only one Product Backlog.
On the other hand, there is one Scrum Master per team. Each team produces its own output and the combined outputs will created a single project increment.
Scaled Scrum
If we need more team members, we need to add more team (rather than a bigger team) and to use Scaled Scrum.
In Scaled Scrum there should be only one person responsible for the business values, so only one Product Owner and only one Product Backlog.
On the other hand, there is one Scrum Master per team. Each team produces its own output and the combined outputs will created a single project increment.
Item tasks
The Sprint Backlog is composed of two elements:
- The items picked from the Product Backlog.
- The taskscomposing the items (warning: those are called“works” in the exam).
Item tasks
The Sprint Backlog is composed of two elements:
- The items picked from the Product Backlog.
- The taskscomposing the items (warning: those are called“works” in the exam).
Developing
Developing: specifying, designing, coding, testing, integrating, documenting, etc.
A developer is anyone who is directly involved in creating the product: analyst, architect, programmer, tester, UI designer, etc.
Developing
Developing: specifying, designing, coding, testing, integrating, documenting, etc.
A developer is anyone who is directly involved in creating the product: analyst, architect, programmer, tester, UI designer, etc.
Definition of Done
The Definition of Done defines everything we need to do for all items in our Product Backlogs, such as:
- Development processes
- Quality criteria
- Non-functional features
The Definition of Done is defined by the Organization (by default), because it will depend heavily on the policies we have within the Organization. It will give the minimal requirements for the Definition of Done at the Organization level.
The Development Team will update this minimal or organization-level Definition of Done to better accomodate the project’s requirements. There are more constraints in this instance of the Definition of Done.
If we do not have a Definition of Done at the Organization level, the Development Team will create it from scracth for their project.
Definition of Done
The Definition of Done defines everything we need to do for all items in our Product Backlogs, such as:
- Development processes
- Quality criteria
- Non-functional features
The Definition of Done is defined by the Organization (by default), because it will depend heavily on the policies we have within the Organization. It will give the minimal requirements for the Definition of done.
The Development Team will update this minimal Definition of Done to better accomodate their needs.
Definition of Done
If we have multiple teams working on the same project, we can have multiple Definition of Done.
Those multiple Definition of Done need to be compatible with each other in a way they will create an integrated output/increment.
Definition of Done
If we have multiple teams working on the same project, we can have multiple Definition of Done.
Those multiple Definition of Done need to be compatible with each other in a way they will create an integrated output/increment.
Measuring Performance
Measuring Performance is usually presented as a burn-down chart, but it is not mandatory. We can measure Spring and Project performance.
- Project Performance is managed by the Product Owner since the Project Performance heavily depends on the Product Backlog (for which the Product Owner is responsible for). We measure the Project Performance at least once per Sprint.
- Sprint Performance is managed by the Development Team. We manage the Sprint Performance once a day.
Measuring Performance
Measuring Performance is usually presented as a burn-down chart, but it is not mandatory. We can measure Spring and Project performance.
- Project Performance is managed by the Product Owner since the Project Performance heavily depends on the Product Backlog (for which the Product Owner is responsible for). We measure the Project Performance at least once per Spring.
- Spring Performance is managed by the Development Team. We manage the Spring Performance once a day.
Daily Scrum
The developers are all accountable for the progress of the report (shared accountability), hence they need to synchronize with each other to know what is going on. This is done during the Daily Scrum meeting.
Each Developer Team member answers the following points:
- What I did since yesterday
- What I am going to do until tomorrow
- The problems I may have
The Developers are the only project members to participate to the Daily Scrum meeting. Others can attend.
Synchronizing
The developers are all accountable for the progress of the report (shared accountability), hence they need to synchronize with each other to know what is going on. This is done during the Daily Scrum meeting.
Each Developer Team member answers the following points:
- What I did since yesterday
- What I am going to do until tomorrow
- The problems I may have
The Developers are the only project members to participate to the Daily Scrum meeting. Others can attend.
Cancelling the Sprint
We can cancel a particular Sprint when the Sprint (Goal) doesn’t make sense anymore and/or has become obsolete. This can be initiated by the Product Owner.
Due to the short duration of Sprints, cancellation rarely makes sense and are very uncommon.
Cancelling the Sprint
We can cancel a particular Sprint when the Sprint (Goal) doesn’t make sense anymore. This can be initiated by the Product Owner.
Due to the short duration of Sprints, cancellation rarely makes sense and are very uncommon.
Sprint Review
The purpose of the Sprint Review is to show the increment to the customer and receive feedback. It is an informal meeting. Typically it lasts 4 hours for a one-month Sprint.
The Scrum Team provides two main items:
- A Demo of the increment
- The product Owner updates the customers about the project’s performance
Based on those 2 items, the customers provide feedback.
Sprint Review
The purpose of the Sprint Review is to show the increment to the customer and received feedback. It is an informal meeting. Typically it lasts 4 hours for a one-month Spring.
The Scrum Team provides two main items:
- A Demo of the increment
- The product Owner updates the customers about the project’s performance
Base on those 2 items, the customers provide feedback.
Sprint Retrospective
The Sprint Retrospective is part of the Continuous Improvement philosophy. It aims at finding a way to improve our project.
There are two main categories for project’s improvement:
- Improvement in the process: done through Retrospectives. Retrospectives are done at the end of each Spring.
- Improvement in the product: done through Refactoring. The goal is to improve the code without changing it’s behavior, it is done continuously. We reduce the Technical Debt.
Typically the Sprint Retrospective lasts 3 hours in a one-month Sprint.
Sprint Retrospective
The Sprint Retrospective is part of the Continuous Improvement philosophy. It aims at finding a way to improve our project.
There are two main categories for project’s improvement:
- Improvement in the process: done through Retrospectives. Retrospectives are done at the end of each Spring.
- Improvement in the product: done through Refactoring. The goal is to improve the code without changing it’s behavior, it is done continuously.
Typically the Sprint Retrospective lasts 3 hours in a one-month Sprint.
Product Backlog Refinement
Product Backlog Refinement or Product Backlog Grooming is done continuously.
A common way of refining the Product Backlog is to breakdown the items into smaller tasks that are more meaningful for the Development Team than the simple user story.
Product Backlog Refinement
Product Backlog Refinement or Product Backlog Grooming is done continuously.
A common way of refining the Product Backlog is to breakdown the items into smaller tasks that are more meaningful for the Development Team than the simple user story.
Product Backlog Refinement
When items are first created in the Product Backlog, they are usually very general and “big”. As soon as the items reach the top of the Product Backlog, we break them down to small items. As we go down the Product Backlog, we break items down to medium-sized items which later will be broken down to small-sized items. As they are broken down, items can be reordered in the Product Backlog.
(Small) Items are then moved to the Sprint Backlog. When doing so, we usually use a kind of Quality criteria (item is small enough and ready).
Product Backlog Refinement can happen anytime. When the Product Owner adds new items to the Product Backlog, he/she goes to the team, explains the new items and asks for estimation. The Product Backlog Refinement process shouldn’t take more than 10% of the Developer Team’s time.
During the Sprint planning, all items have already been explained and estimated.
Product Backlog Refinement
When items are first created in the Product Backlog, they are usually very general and “big”. As soon as the items reach the top of the Product Backlog, we break them down to small items. As we go down the Product Backlog, we break items down to medium-sized items which later will be broken down to small-sized items. As they are broken down, items can be reordered in the Product Backlog.
(Small) Items are then moved to the Sprint Backlog. When doing so, we usually use a kind of Quality criteria (item is small enough and ready).
Product Backlog Refinement can happen anytime. When the Product Owner adds new items to the Product Backlog, he/she goes to the team, explains the new items and asks for estimation. The Product Backlog Refinement process shouldn’t take more than 10% of the Developer Team’s time.
During the Sprint planning, all items have already been explained and estimated.
Roles - Product Owner
The main role of the Product Owner is to maximize value of the product by:
- Creating Product Backlog items
- Assigning (business) values to items
- Ordering the items
- Explaining the items (to customers and developers)
- Measuring project performance
- Contacting the customers
The Product Owner has the following characteristics:
- Owns the Product Backlog
- Is always 1 person
- Can be influenced (customers, developers, etc.)
- Is respected by everyone
- Can delegate
- Full-time or part-time
Roles - Product Owner
The main role of the Product Owner is to maximize value of the product by:
- Creating the items
- Assigning (business) values to items
- Ordering the items
- Explaining the items (to customers and developers)
- Measuring project performance
- Contacting the customers
The Product Owner has the following characteristics:
- Owns the Product Backlog
- Is always 1 person
- Can be influenced (customers, developers, etc.)
- Is respected by everyone
- Can delegate
- Full-time or part-time
Roles - Scrum Master
The main role of the Scrum Master is to take care of the process by:
- Ensuring Scrum is understood
- Ensuring Scrum is used properly/enacted
- Helping (Product Owner, Developers, etc.) with techniques
- Faciliting the events/meeting (not mandatory)
- Removing the impediments/obstacles
- Helping the organization to adopt Scrum
The Scrum Master has the following characteristics:
- one Scrum Master role for each team
- Full-time or part-time
- Servant-leader
- A manager (of the process, not managing people)
- Not a project manager
- Not a team leader
Roles - Scrum Master
The main role of the Scrum Master is to take care of the process by:
- Ensuring Scrum is understood
- Ensuring Scrum is used properly/enacted
- Helping (Product Owner, Developers, etc.) with techniques
- Faciliting the events/meeting (not mandatory)
- Removing the impediments/obstacles
- Helping the organization to adopt Scrum
The Scrum Master has the following characteristics:
- one Scrum Master role for each team
- Full-time or part-time
- Servant-leader
- A manager (of the process, not managing people)
- Not a project manager
- Not a team leader
Roles - Development Team
The main role of the Development Team is to create the increments by:
- Developing
- Estimating (the story points)
- Selecting items for the Sprint Backlog (from Product Backlog)
- Measuring Sprint Performance
- Calculating Velocity
- Composing the Definition of Done (DoD) or refine it
- Making the technical decisions
The Development Team has the following characteristics:
- 3 to 9 people
- Have no titles (share accountability)
- Preferably full-time
- Self-organized: make decisions instead of receiving orders
- Cross-functional: the whole group as the expertise needed for the project
- Have a sustainable pace: we don’t keep working overtime, as it’s not productive, and lowers the quality
Roles - Development Team
The main role of the Development Team is to create the increments by:
- Developing
- Estimating (the story points)
- Selecting items for the Sprint Backlog (from Product Backlog)
- Measuring Sprint Performance
- Calculating Velocity
- Composing the Definition of Done (DoD) or refine it
- Making the technical decisions
The Development Team has the following characteristics:
- 3 to 9 people
- have no titles (share accountability)
- preferably full-time
- self-organized: make decisions instead of receiving orders
- cross-functional: the whole group as the expertise needed for the project
Roles - Scrum Team
The Scrum Team is:
- Self-organized
- Cross-functional
- Without any additional role (e.g. external architects, external QA, etc. ). An exception would be a PMO focused on programs or portfolio management.
- Delivering incrementally and iteratively
All roles in the Scrum Team are designed to maximize:
- Creativity
- Flexibility
- Productivity
Roles - Scrum Team
The Scrum Team is:
- Self-organized
- Cross-functional
- Without any additional role (e.g. external architects, external QA, etc. ). An exception would be a PMO focused on programs or portfolio management.
- Delivering incrementally and iteratively
All roles in the Scrum Team are designed to maximize:
- Creativity
- Flexibility
- Productivity
Events
- Sprint Planning: creates the Sprint Backlog (Developers) and the Spring Goal (Scrum Team).
- Daily Scrums: synchronizing the developers with each other (Developers)
- Sprint Review: generates feedback and uses that feedback to revise the Product Backlog (Scrum Team & Customers)
- Sprint Retrospective: continuous improvement (Scrum Team)
All those events are a formal opportunity to inspect and adapt, and enable critical transparency.
Events
- Sprint: creates value through an increment
- Sprint Planning: creates the Sprint Backlog (Developers) and the Spring Goal (Scrum Team).
- Daily Scrums: synchronizing the developers with each other (Developers)
- Sprint Review: generates feedback and uses that feedback to revise the Product Backlog (Scrum Team & Customers)
- Sprint Retrospective: continuous improvement (Scrum Team)
All those events are a formal opportunity to inspect and adapt, and enable critical transparency (except for the Sprint itself!).
Sprint Definition
The goal of Sprints is to create Increments.
Increments are:
- a potentially releasable (release = put something into operation) piece of software. You may or may not release it.
- potentially shippable
- usable for the end users
- done based on the Definition of Done
The Product Owner decides about releases.
Sprint Definition
The goal of Sprints is to create Increments.
Increments are:
- a potentially releasable (release = put something into operation) piece of software. You may or may not release it.
- potentially shippable
- usable for the end users
- done based on the Definition of Done
The Product Owner decides about releases.
Sprint Planning - Details
The Sprint Planning has 2 different parts.
- We will create the Sprint Goals and pick the items for the Sprint Backlog - WHAT
- We will create the Work (tasks) - HOW
The tasks should have been defined/explained/estimated during the Product Backlog Refinement (it is a continuous activity). Remember the Product Backlog Refinement is max 10% of the Developers time.
Sprint Planning - Details
The Sprint Planning has 2 different parts.
- We will create the Spring Goals and pick the items for the Sprint Backlog - WHAT
- We will create the Work (tasks) - HOW
The tasks should have been defined/explained/estimated during the Product Backlog Refinement (it is a continuous activity). Remember the Product Backlog Refinement is max 10% of the Developers time.
Sprints
We don’t make any changes during the Sprint that affects the Sprint Goal such as:
- Composition of the Team
- Quality Goals
- Definition of Done
- Sprint Backlog
- Items in the Sprint Backlog
- Work (tasks) in the Sprint Backlog <- This changes during the Sprint!
The Work (tasks) MUST during the Sprint! We only prepare some of them in the Sprint Planning.
Sprints
We don’t make any changes during the Sprint that affects the Sprint’s goal such as:
- Composition of the Team
- Quality Goals
- Definition of Done
- Sprint Backlog
- Items in the Sprint Backlog
- Work (tasks) in the Sprint Backlog
The Work (tasks) can change during the Sprint!
Changes during Spring
2 exceptions for which the Sprint Backlog items list can be modified:
- If an new item is requested by the customers to be added during the Sprint, it is the Product Owner’s responsibility to accept or to deny the new item for the current Sprint. The developers do not have to take that decision.
- If the Developers are done with all the items in the Sprint Backlog and the Sprint is not over yet, they will pick one item from the Product Backlog and move it to the Sprint Backlog.
Otherwise, during the Sprint, changes are classified as below:
Changes during Spring
2 exceptions for which the Spring Backlog items list can be modified:
- If an new item is requested by the customers to be added during the Spring, it is the Product Owner’s responsibility to accept or to deny the new item for the current Sprint. The developers do not have to take that decision.
- If the Developers are done with all the items in the Spring Backlog and the Spring is not over yet, they will pick one item from the Product Backlog and move it to the Spring Backlog.
Otherwise, during the Sprint, changes are classified as below:
Sprint Review
Sprint Review is an informal meeting. We provide the customers with the following:
- Demonstrating the increment
- Providing progress information (usually burn-down chart)
Measuring progress:
- Project: once a Sprint
- Sprint: once a day
Sprint Review
Sprint Review is an informal meeting. We provide the customers with the following:
- Demonstrating the increment
- Providing progress information (usually burn-down chart)
Measuring progress:
- Project: once a Sprint
- Sprint: once a day
Scaled Scrum
Scaled Scrum is when we have more than one team.
In Scaled Scrum, we have:
- Only one Product Owner
- Multiple Scrum Master positions, one per team (same person can fill this position for different teams)
- One Product Backlog
- Multiple Sprint Backlog, one per team
- Multiple Definition of Done, one per team (reminder: DoD need to be compatible with each other to deliver an integrated increment)
Scaled Scrum
Scaled Scrum is when we have more than one team.
In Scaled Scrum, we have:
- Only one Product Owner
- Multiple Scrum Master positions, one per team (same person can fill this position for different teams)
- One Product Backlog
- Multiple Sprint Backlog, one per team
- Multiple Definition of Done, one per team
Scrum of Scrums
Scrum of Scrums is meant to synchronize the different teams. A representative of each team (Daily Scrum) will attend the Scrum of Scrums. It is usually a developer and can change over time.
In the Scrum of Scrums meeting, we have the 3 traditional questions plus a question regarding the dependencies among teams.
Scrum of Scrums
Scrum of Scrums is meant to synchronize the different teams. A representative of each team (Daily Scrum) will attend the Scrum of Scrums. It is usually a developer and can change over time.
In the Scrum of Scrums meeting, we have the 3 traditional questions plus a question regarding the dependencies among teams.
Tailoring
Tailoring is the customization of the methodology used for the project. Scrum is an empirical framework.
Methodology (Prince2, PMP) <> Framework (Scrum)
Usually Tailoring does not apply to Frameworks/Scrum, since they provide the bear minimum.
Examples of Tailoring:
- Changing names
- Removing elements
- Adding elements
- Adding techniques (allowed by Scrum)
Tailoring
Tailoring is the customization of the methodology used for the project.
Methodology (Prince2, PMP) <> Framework (Scrum)
Usually Tailoring does not apply to Frameworks/Scrum.
Examples of Tailoring:
- Changing names
- Removing elements
- Adding elements
- Adding techniques
3 Pillars of Scrum
- Transparency
- Inspection
- Adaptation
3 Pillars of Scrum
- Transparency
- Inspection
- Adaptation
