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.
