Scrum Artifacts
About
Scrum Artifacts can be examined frequently, but it should not get in the way of the work.
The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems.
Product Goal ⭐
Its is contained within the product backlog. The PO is responsible for developing and explicitly communicating the product goal. It describes a future state of the product, which can serve as a target for the scrum team to plan against. It is the long term objective for the scrum team.
The team might need multiple Sprints to fulfill it.
What fulfills the product goal? What do we need to do to get there? the rest of the product backlog
The product itself cannot be the goal.
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical products, or something more abstract.
You can have MULTIPLE products goals.
BUT the Scrum Team must ONLY focus on ONE product goal at a time.
Before moving on the next, the current one must be fulfilled or abandoned.
Multiple scrum teams should also SHARE the same product goal.
Product Vision
This is where we define the boundaries for our product.
Such as defining a value proposition and identifying the key stakeholders and users or customers.
It makes a link between the product and the business strategy.
The Scrum Guide does not cover much of it.
Product Strategy
Is where we define how the vision will be realized.
This is where the PRODUCT GOALS come in.
Part of the product strategy is to define the product goals.
They are manifestations of the product strategy, a measurable direction towards the product vision.
Product Backlog ⭐
The Product Backlog commits to the Product Goal.
As long as a Product exists, its Product Backlog also exists.
An emergent, ordered list of what is needed to improve the product.
What is needed:
Means that the product backlog is the single source of work for the scrum team.
It lists all:
Features, Functions, Requirements, Enhancements, and Fixes,
that constitute the changes to be made to the product in future releases.
Emergent:
The product log follows what we call just-in-time requirements.
Meaning that we only detail enough items ready for the up coming Sprint.
A product backlog item can be considered READY, when it can be done within one Sprint.
But Ready is not a gate.
And why Scrum follows this practice?
Because we expect things to change.
And detailing everything becomes WASTE.
A product has ONE product backlog, no exceptions.
Ordering the Product Backlog is a Critical activity.
Product Backlog must be DEEP:
Detailed
Consider dependencies.
Estimated
Insurance against risks.
Emergent (It Evolves)
Value, could be inferred with
Kanofor instance.
(P)Ordered
Estimated effort, using
Story Points.
So considering this, INVEST on your Product Backlog wisely:
(I)ndependent
Should aim for having independent items.
(N)egotiable
The items must be a result of a conversation between business and dev.
(V)aluable
Must have business value.
(E)stimatable
Must have enough information or the team have enough knowledge to estimate the effort to deliver it.
If this cannot be done, you can apply a technique called SPIKE.
Where part of the team capacity is reserved to explore an item to the point they are now able to estimate it.
(S)mall
Must be small enough (just-in-time), to ease planning and ordering, and so it can fit a Sprint.
(T)estable
The team must be able to verify if it is done.
Acceptance criteria. (From User Stories)
What does the product backlog details:
The attributes vary with the domain of work and COULD be:
A description,
Order,
and Size.
Usually a healthy product backlog is like this:
Small part of it ready for Sprint,
These are the more clear, detailed items, that are higher ordered.
The more important stuff, that the team will focus.
The rest are unrefined items, and are not detailed, following the practice of just-in-time.
Product backlog (Description)
Can be divided in 3 categories, before it is ready to be considered a feasible item.
The LARGE SIZE and LOW DETAILED items (EPIC):
Called EPICs.
Are briefly described product features.
They are too large to fit a Sprint.
They are the abstract things that need to be done, but weren't yet refined.
The SMALL SIZE and HIGH DETAILED items:
These small refined ones usually are:
User Stories:
Have three components:
Card
Is a written description of the functionality that will be valuable to either a user or a customer.
So it is written from the perspective of a customer or user.
Conversation
Represents the collaboration between the PO, the business people, and the technical people.
Confirmation
A list of criteria that the Scrum Team, will defined to serve as a verification, if the product delivered suits the needs.
The most popular notion of a User Story description is:
As an [actor] (actor: the User, the Customer)
I want [action] (action: Something that the actor wants, or needs to do)
so [end] (end: It is important to know the motivation for the user to want to do something, so the team can find the best way to attend to his needs)
Good exemples:
[e-commerce]: As a sales manager I want to generate a monthly sales report so that I can verify if the teams goals were fulfilled.
[airbnb]: As a rentant I want to reserve an apartment online to ease my vacation planning.
[proj4me]: Team member can visualize his/her current task to be aware of his/her to-do list.
Bad exemples:
The houses project will be in autocad.
The software will be written in C.
Product backlog (Order)
4 factors for ordering the product backlog items.
Size (Story Unit - Planning Poker)
Risk
Value (Business Value) (Very context dependent) (Kano Model)
Dependencies
Lets order some backlog items considering the Business Value:
1
10
2
2
12
1
3
6
3
4
5
4
5
4
5
But we could make it better and also consider its Size, and maybe order it by ROI (Return on Investment)
1
10
5
2
2
2
12
10
1.2
4
3
6
3
2
3
4
4
2
2.5
1
5
5
5
0.8
5
But maybe ordering it like this could not be possible due to a Technical or Business Dependency. We always try to avoid having dependent product backlog items, but sometimes its just too hard to fulfill this.
Ex.:
How can the user Sign-in to the system if he can't Sign-up. Sign-up would have to come firs as a technical dependency.
So lets say that User Story 1 depends on the User Story 2:
1
10
5
2
2
4
2
12
10
1.2
4
3
3
6
3
2
3
2
4
4
2
2.5
1
1
5
5
5
0.8
5
5
User story 3 goes before 1 now because they have the same ROI, but 3 does not depend on no one.
Now for the Risk. For instance, suppose that you are developing a augmented reality app. The augmented reality is what makes the product stands out, and your company never worked with it before. Independent of the other factors, you might want to put the product backlog items related to augmented reality on the top.
Because if, for instance, the programming language or framework that you are planning to use does not support it, you will want to know that before wasting time developing other features.
Product backlog (sizing/size) (estimation)
In agile a 'lightweight' approach is taken for estimating the time it will take for doing the work.
Scrum does not prescribe any rules about estimates.
The most popular measure unit is the Story Point. Which is an Agile alternative to hours/days.
And the most used estimation technique is the Planning Poker.
Story Point (Measure Unit)
In agile it is not recommended to estimate work units in time, because it generates a lot of effort. And you will end up with inaccurate estimates anyways.
Even thou management WILL ask for estimation in TIME, the ideia is to use relative sizing.
For instance, assume we have a pool of 25m, and it is asked how long it would take to swim across it.
Times would be different depending on the person. So the approach is to think of the swimming pool length as relative size considering other lengths like 50m, 75m and etc.
So this 25m one would be of length 1, the 50m would be 2, and so on.
This is relative size thinking.
The story points use the semi-fibonacci scale.
Up to 13, the values are calculated by adding the two last ones: $(2 + 3 = 5)$, $(5 + 8 = 13)$ After 13 it is arbitrary since, we humans often fail to estimate big things.
In Agile we don't estimate thinking about having me or you doing the task, is is about the team.
It is a TEAM METRIC.
But you can never compare teams productivity using Story Points.
Planning Poker
Is an estimation technique. Is a collaborative consensus based agile estimating technique, in which each developer holds a deck of cards containing the numbers we just discussed, having each number, represent a story point.
Then the PO is going to read a product backlog item, developers discuss that item: to know the size, the complexity, that do they need to do, the risks involved for developing it.
After, each developer privately selects one card to represent his estimate.
So if our estimators selected the same value, that becomes the estimated value. If not they discuss their estimates, and then go on another round, until consensus is reached.
Tips on starting a planning from 0:
You will get the easiest backlog item (User Story), the one that could be done in a few days, and give it a 2.
After that, you estimate the remaining ones in comparison to that one and that's it.
Notice that these estimates depend on the Definition of Done.
So the more rigorous are the criteria to have a Done increment, in terms of, quality and documentation, the more costly it is to develop it.
Product backlog (value / business value)
Scrum does not prescribe any techniques for this purpose.
The Kano model
It is based on classifying items into one of three categories:
Mandatory
It is about things that if your product has the customer won't care a lot, but if it doesn't have, they will hate it.
All theses features, MUST be included in the Backlog.
Linear
Are features that the more you have, the more you can charge the customer.
Backlog must include as many as possible.
Exciter
It is about unknown desires.
The customer wont be upset if you don't deliver it, because they don't even know they want it.
But if you do deliver, its the thing that makes it stand out.
You should leave a little room for you exciters.
So, for each backlog item ask two things to users or customers:
One question on the Function form.
The other in Dysfunction form.
After the data gather, analyse it:
Mandatory feature:
Functional: 'Expect', 'Are Neutral' or 'Live with it'.
Dysfunctional: 'Dislike'.
Linear feature:
Functional: 'Like'.
Dysfunctional: 'Dislike'.
Exciter feature:
Functional: 'Like'.
Dysfunctional: 'Except', 'Neutral', 'Lives'.
Product backlog (Refinement)
It is the act of breaking down and further defining product backlog items into smaller more precise items.
The ordering of Product Backlog items is also considered a Refinement.
Usually, it is what enables getting the backlog items Ready.
But it is ok for the team to try implement a backlog item that is not 100% Ready.
The scrum team decides how and when refinement is done.
The Definition of Ready ⭐
Is not and official Scrum Guide practice.
It is a set of criteria that defines when a product backlog item is ready to be executed. Usually we have at least these criteria:
Acceptance criteria defined.
Team understands what has to be done.
Fits a Sprint.
Monitoring progress toward Goals ⭐
Should be inspected frequently and diligently to detect potentially undesirable variances or problems.
Burn-Down
The ideia is to burn, from top to the bottom, the work to be done to reach a goal. Usually the goal is to deliver the product backlog.
So you will add up all the estimate points, using for instance Story Points, for all the backlog items. And update a chart like these after each Sprint.
Lets also assume that there is a Goal to reach at Sprint 8.
So the read line, would be a linear estimation from the beginning to the Goal. And after each sprint, you would set the remaining points to be done. If your line is above the estimation, 'You are Late'. If your line is bellow the estimation, 'You are on Time'.
The problem with this approach, is that the product backlog, is a living artifact, and it changes with the Sprints.
So the Burn-down is not really good to show these modifications.
In this example, it might seem that the team did not burn any points during the Sprint, but they could have burn 10 points, and due to change in the backlog, more user stories were added, and so more points were added again.
It would be even worse, if more points were added than burned.
Burn-Up
It is similar to the Burn-down, but instead of going top to bottom, we go from bottom to up.
The catch is that, the Blue line represents the work DONE/POINTS BURNED by the team.
And the Red line represents the work to be Done. This line can either stay horizontal if nothing is added to the Backlog, or can go up, representing more work added to be done.
Cumulative Flow
While the Burn-Up chart show progress towards a goal, the cumulative flow diagram shows the distribution of all product backlog items across various states over time.
The Increment ⭐
The increment commits to the Definition of Done.
The Scrum Team is accountable for creating a valuable, useful Increment every Sprint.
It is developed during Sprints, and it is cumulative. In other words, for the first Sprint, the Increment is the sum of all the backlog items completed.
For the second one, the Increment is a sum of all the backlog items during the Sprint and the value delivered of all previous Sprints.
But since when a backlog item meets the Definition of Done, a Increment is born, multiple Increments may be created within a Sprint.
However, the sum of such Increments is presented a the Sprint Review.
The Increment is KEY for successfully driving changes in Scrum.
The feedback on the Increment will drive the Scrum Team into optimizing the delivered value. And this is why we say that the Increments supports empiricism.
You DO NOT need make a Release at the end of every Sprint.
The Scrum Team can make the Release whenever it feels like it is valuable.
The Sprint is NOT A GATE, Releases might be performed during a Sprint.
The Definition of Done ⭐
Defines what is needed for work to be considered done.
A formal description of the state of the Increment when it meets the quality measures requered for the product.
The moment a backlog item meets the Definition of Done, an Increment is born.
If a backlog item does not meets the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the backlog for future consideration.
Such criteria might be:
Quality assurance Architecture Non-functional requirements Process Management Configuration management
Acceptance Criteria is specific for ONE User Story.
The Definition of Done, englobes all of them.
It is strongly related to QUALITY.
Who defines the Definition of Done?
The organization, BUT, if it does not, then the Scrum Team MUST define one.
The Definition of Done, can be set by the Organization, if it requires standard quality or requirements.
The Scrum Team can than have these as minimal Definitions, and then add more if necessary.
Also two scrum teams, can have different Definitions of Done, BUT, since an Increment can ONLY HAVE ONE, these two team MUST have a MUTUAL set of common definitions, and then add to it.
The Definition of Done might evolve with time, and is expected to include more stringent criteria for higher quality. But it can also edit or remove criteria.
It can happen that by adding more criteria, the team will have to do more work in previous Done Increments.
The Definition of Done shouldn't change in the middle of the Sprint
Technical Debts
It is not cited by the Scrum Guide.
It is consequences of poor software development practices. Might lead to code decay and architecture deterioration.
In summary, a code with high technical debt means that its really hard to work with and the cost of change is high.
It is not necessarily bad, but maybe it was just a part of the learning process.
Sprint Backlog ⭐
The Sprint Backlog commits to the Sprint Goal.
The Developers commit to the Sprint Goal.
Is the OUTPUT of a Sprint Planning. The Sprint Backlog is Emergent, meaning that it can be UPDATED, during the Sprint.
Only the Developers are allowed to change the Sprint Backlog.
It is composed of:
Sprint Goal (Why?)
Selected PBI's (Product Backlog Items) (What?)
Plan (How?)
The Sprint Goal NEVER changes, but the selected PBI's or the Plan can change.
The Sprint is not about delivering the selected PBI's, BUT ACHIEVING the Sprint Goal.
Last updated