Scrum
Last updated
SC - Efficient Development
Last updated
A mechanism to optimize the value delivery system.
Scrum is used to drive the work and effort we take to deliver value in complex environments.
Is a way to help deal with complex problems.
Is a mechanism to guide changes.
So scrum is a agile framework that you can use as a foundation to work on complex problems.
Not a process.
Or technique.
Or methodology.
Or definitive method.
But it is a general-purpose that MUST be complemented given your domain.
Why scrum is a framework?
Because, it can be improved upon.
Can be defined with two dimensions:
Simple problems:
Easy to predict what it needs AND to develop.
Complicated problems:
Easy to define, but difficult to come to an agreement on how to solve it.
Or easy to solve, but hard to get to an agreement on what needs to be done.
Complex problems:
In a complex environment, you only know 1 thing for sure: You don't know everything.
You cannot early in the process predict if you are going in the right path. (You will have to change along the way)
Chaotic problems.
There are two perspectives:
Effectiveness:
Delivering the right product. (The "What" dimension)
Efficiency:
(The "How" dimension)
Define system attributes such as:
They serve as constrains or restrictions on the design of the system across the different backlogs.
There are ALWAYS nonfunctional requirements.
They should be incorporated into every Increment.
Some of them can be added to the Definition of Done.
Some of them can be added to the Product Backlog.
In a company that uses Scrum and has PMO, the PMO proper role is:
Manages portfolios and programs and facilitates the application of techniques that complement Scrum.
What is a Project?
Every project is fundamentally unique, since there are variables that change from one to the other, event if the two projects are to achieve the same product.
It is a temporary effort that produces something unique. (Be it a product, service or other outcome)
For instance: Designing a new car is a project.
Project Management
Is the process of leading the work of a team to achieve goals and meet success criteria within specified restrictions suck as time and budget.
What is an Operation?
Are permanent in nature, which means that they flow continuously.
Instead of being considered a unique effort, it often repeats the same process over and over.
For instance: Manufacturing a car, is an operation.
Project and Operation
They have similarities like:
Having a purpose
Using constrained resources:
Time
Money
People
Require management activities.
Planning
Execution
Control
Also known as plan-driven or proactive.
Focuses on planning everything that will be made from the beginning until the end of the project.
You need to predict and plan, in detail, everything that will be done from the project start to end.
Produces lots of documentation.
Changes end up being resisted and bureaucratized.
The product, service or outcome is made available ONLY during project closure (Late Stages).
Commonly used in traditional projects.
Initiation
Planning
One difference of traditional from agile, is the effort on planning on traditional is mostly made during the early stages of the project.
This means that at an early stage, you need to predict as most as possible everything that will happen after.
Execution
Closure
Monitoring and Control
You as a client will have to face the situation of knowing that you don't know exactly what you want,
Will sign a contract for a project that you know that was not very well defined,
And accept that you will not be allowed to change it later,
Because changes at the end are very costly.
Low scope uncertainty.
When the scope will be well defined since the beginning of the project, and very unlikely to change.
Low client availability.
And others...
Can be controlled and avoided.
Happens and we have no control over them.
The waterfall approach also known as traditional, pro-active, predictive, plan driven and discipline.
In waterfall, you plan on develop the perfect plan then follow it.
The problem comes because the correct vision, hardly is the initial one, as things change in the business world.
In theory you could change the plan, to adapt to changed vision. But in practice, it would not change the vision much, because of the associated cost and bureaucracy.
As a result, two thing can happen:
The implemented changes might not be enough to deliver the correct vision.
We might at some point get the correct vision, but it will be so late, that it might be useless.
Is best suited for problems with low uncertainty.
Like build bridges or buildings.
In agile we assume initially that we don't know the target.
We know that we cannot come up with the perfect plan.
The ideia is to deliver something close to the customer needs, in short cycles, and learn with the experience.
IKIWISI -> I Know it When I see it.
Agility means responding to change.
It is best suited for complex environments.
Like softwares.
Is being agile the same thing as being rapid or fast? NO.
Just being rapid is not enough, because all the adaptations in vision (aka, cycles), are considered waste. So if you are just rapid, you just deliver waste faster.
But if you are agile AND slow, you end up just like Waterfall.
For achieving agility, you must be rapid.
Agility is more related to getting the correct product, but we need to get there efficiently by reducing the waste.
Reducing waste is what is known as being lean.
We produce waste whenever we work on anything not part of the correct product vision. Thus the value of agile comes from being capable of making the necessary adjustments with the minimum waste as possible .
Succeeding with agile and scrum requires being rapid and lean.
Individuals and Interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
Not explicitly presented in the agile manifesto.
See setbacks as LEARNING OPPORTUNITIES.
Adopt
SHORT DELIVERY CYCLES to be able to do rapidly,
COLLABORATION between business and technical,
AND CHANGE, handle changes not seeing them negatively.
Focus on DELIVERING VALUE, what the customer needs.
We focus on these thing, and everything else is waste.
Individuals and Interactions over processes and tools
All of them are touching some part of the elephant and thinking something, but they are all wrong. But if they share their knowledge, they will most probably guess the correct think.
This is a analogy of a complex problem.
A massive problem to be identified.
People with different set of skills, experience, view points.
And only working together they can work efficiently.
Working software over comprehensive documentation
Remember IKIWISI, if the problem is complex, the customer needs to see something tangible so they can have an authentic experience using it, and give back their feedback.
So focusing more on delivering the product, and less on documentation also increases our responsiveness to change.
Customer collaboration over contract negotiation
We don't know precisely what the customer wants. Thus we need them in our side, to help build the right product.
The idea here is having the customer as part of the team. But must require good faith and commitment from both parties.
Responding to change over following a plan
Close related to values 2 and 3. We present a working product to the customer, they see it, touch it, uses it, and gives us feedback. (Collaborate with us)
This feedback might lead to changes in the original plan, and then we respond and change.
Conclusion
The important thing, is that you must VALUE more the thing in the left side. But you also do the things on the right side.
Being agile is not an excuse for not doing the things in the right side.
Can be categorized in 4 categories. (The PPPP, the 4 P's)
Agile principle #1
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software (or Valuable working tangible product).
Can be summarized with these two acronyms:
IKIWISI -> I know it when i see it
The only way to get valuable feedback from the customer, and learn the best path to success, is by delivering valuable products that the customer can use and have an authentic experience with the product. YAGNI -> You ain't gonna need it
Is about eliminating waste, and maybe finding a shortcut.
Because studies have shown that most features of a product are never used.
And only 20% of the features bring 80% of the revenue.
Agile principle #2
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Changes are what lead to success in complex environments. It is part of the process of learning more about the problem.
Related to the #1 principle, since changes might have been originated from the customer's feedback.
Agile principle #3
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Because we need to inspect what have been done, and adapt fast.
Agile principle #8
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Sustainable means that:
Working long hours, over night, or on weekends IS NOT THE WAY to go.
Complex problems, usually requires knowledge workers need to make tough decisions.
This means that working overtime, might show good results in the short term, but on the long term, will lead to issues, stress, overload and lack of motivation.
So in practice this principle, is followed by giving the team alternative to negotiate with business as equals, such as having the developers select the amount of work.
Agile principle #7
Working software is the primary measure of progress.
Agile is about learning and adapting to maximize the value delivery. But value delivery is only achieved by working products. So plans, proposals, or design documents, is usually not considered as progress.
Agile principle #10
Simplicity - the art of maximizing the amount of work not done - is essential.
We have two perspectives:
Business
Think about YAGNI, there is no value delivering things that no one will use. (Lean Thinking)
Technical
Make the solution simple too.
You should only document what is necessary.
Making the doc, simple, short and concise.
Can you automate something, and make your daily routine simpler.
No re-inventing the wheel.
Don't overthink ahead. (By designing all future possible scenarios)
Agile principle #9
Continuous attention to technical excellence and good design enhances agility.
Here we have 3 word.
Quality
Quality
Quality
We don't want to do just one big delivery, but a chain of quick deliveries. Develop only the necessary and let the team what they can do. Give them autonomy.
Stressed out people do crappy stuff. Whenever possible automate your quality assurance and control processes. For instance, use modern DevOps and testing automation practices.
Agile principle #4
Business people and developers must work together daily throughout the project.
Usually in traditional or waterfall projects, the customers are heavily involved at the beginning and end of a project.
Though in agile, we need the customers available throughout the entire cycle, to help the developers to adapt the project. During the development, the technical people will have business related questions, and 80%-95% of these questions should be answered in under 5 minutes. This required availability is a massive mind shift for some business people.
Agile principle #5
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Since agile is based on bottom-up intelligence and self organized teams, what is the role of management?
They must give the team the necessary support and trust them as responsible and capable of doing their best.
The key concept is having serving leaders or leaders who serve, giving the team necessary coaching, mentoring, training and support to be as effective as possible.
Agile principle #6
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Communication is one of the significant causes of project failures.
But sometimes there is need for persistence in the communication, because people are in different timezones, or for other reasons.
Agile principle #11
The best architectures, requirements, and designs emerge from self-organizing teams.
Achieving optimal solutions falls from giving the developers the necessary autonomy to make decisions.
This principle conflicts with the traditional top-down control management, where a single manager concentrates the decision making power.
However, for complex problems it is most likely that the people doing the work, who are immersed in the problems context are better informed than a manager. So we need bottom-up intelligence, and senior management gives the team autonomy to manage and assume responsibility for their own tasks.
Agile principle #12
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
While agile focus on building the right product, it also focus on building it right. In other word, just as the team learn more about the product, they also learn on how to be more effective developing it.
Agile culture is based on proactively, finding what works well, and what does not work well, continually improving.
Scrum is a way of implementing agility.
Studies show that 60% of the teams that claim to be agile, use Scrum as its core framework.
Its a concept on how uncertainty varies through time. The evolution of a product's knowledge over time.
The earlier you are in the projects cycle, the less you know about it, thus the higher the variability.
The more uncertainty involved in the estimate the higher the variability, and it can be used for adjusting our expectations regarding an .
You work with two scenarios:
Worst-case:
Best-case:
Usually variability on software projects are off by a factor of 4, because of VUCA. The higher the variability, the higher the need to be agile.
The more uncertain, complex, ambiguous is the business and technological environment the higher the variability factor will be.
Sets of problems that projects have, and that needs to be dealt with.
V (Volatility)
The level of changes in the environment. The more changes the higher the volatility.
U (Uncertainty)
Is about how much we know about the situation. The more volatile the environment, ambiguous and complex the problem or solution, the higher the uncertainty. If you are not 100% certain, you are dealing with uncertainty.
C (Complexity)
The level of inter connectivity and interdependence of multiple components in the system. The more business rules and technological dependencies the more complex.
A (Ambiguity)
Is about the level at which we understand the meaning of something. Like understand what the user wants given what he described. Environments with high ambiguity, we need to assume an answer so that we can move forward despite not being sure about it.
Agility is a way of dealing with VUCA.
It has been shown that adopting short delivery cycles can reduce the variability estimates from 300% to 60%.
Scrum requires a Scrum Master to foster an environment where:
A product owner orders the work for a complex problem into a product backlog.
The scrum team turns a selection of the work into an increment of value during a Sprint.
The scrum team and its stakeholders inspect the results and adjust for the next Sprint.
Repeat.
The scrum framework is purposefully incomplete, only defining the parts required to implement scrum theory.
This iterative and incremental process is executed until work is done or budget is over and includes refining the product backlog as needed.
Product Backlog
It all starts with the product backlog, which contains all the work to be done, and describes what will fulfill the product goal.
It is maintained by the Product Owner (PO), who makes sure that the top items are the most important ones.
Sprint Planning
Events done for crafting a sprint goal, and for the developers to select the Product Backlog items to be developed during the Sprint.
The sprint goal and the selected items form the Sprint Backlog ⭐.
Sprint Backlog
Also contains an actionable plan for delivering an Increment.
Sprint
During the Sprint which usually lasts at most one month, the developers conduct daily scrums to synchronize their work and maximize their chances of achieving the Sprint Goal.
During the sprints, the moment a Product Backlog item meets the Definition of Done, an increment is born.
Increment
Is a concrete stepping stone toward the product goal.
At the end of each sprint the scrum team conducts two events.
First they run a Sprint Review event in which the scrum team and the invited stakeholders inspect to produced increment, giving informed feedback that might adapt the product backlog.
Afterward the scrum team members run a Sprint Retrospective event, in which they inspect and adapt their interactions, processes, and the definition of done, which might impact the next sprint planning event.
We start with a set of ideas and transform them into Value by working.
Product Backlog
Is where all the ideias are stored. It is not intended for documentation itself but to bring transparency to the process and create alignment between business and technical people.
The feasibility of delivering value is highly affected by the quality of the product backlog.
It is not only refined and changed after sprint reviews, its refinement is an ongoing process in which the scrum team collaborates on the details of the product backlog items.
Although the PO is the one accountable for it, the developers are the ones responsible for the sizing of the products backlog items. The PO may influence them by helping them understand and select trade-offs.
Sprint Backlog
It is the backlog generated from the sprint planning, that holds:
The scrum team agrees on a sprint goal;
Selects a set of product backlog items, to be worked on during the sprint;
Defines an actionable plan for delivering the increment;
Increment
Is the outcome of a sprint. The increment is a vertical delivery, having all the layers as part of the product. The increment is Scrum's way of manifesting real value. (This is where the work is done) It is possible to have multiple increments in a sprint.
In complex problems, asking user what they want is not enough. They will only know when IKIWISI.
Horizontal delivery (Iterative)
Vertical delivery (Incremental)
Since Scrum is both Iterative and Incremental it looks something like this:
Product Owner
Is the single person accountable for defining what will be done and in what sequence. He needs to write a good product backlog. He needs to collaborate with the Scrum team and stakeholders.
Developers
Are the ones that get the work done. They directly work to deliver the increments.
Scrum Master
Good Scrum Masters are invisible. They do not get in the way of the other team members, but empower them. They observe and support the scrum team making scrum work effectively.
One of their jobs is to detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.
Sprint
Lasts at most one month.
Sprint Planning
Is the first thing done in the beginning of a Sprint. Lasts at most 8 hours.
The scrum team agrees on a sprint goal;
Selects a set of product backlog items, to be worked on during the sprint;
Defines an actionable plan for delivering the increment;
Daily Scrum
Each day during the sprint, the developers hold this daily scrum. Lasts at most 15 minutes.
A quick way for the developers to discuss how to optimize its chances to reach the sprints goal.
Sprint Review
A event at the end of the Sprint, lasting at most 4 hours.
It is when the scrum team gets along with stakeholders to discuss the product being developed, including what was developed during the sprint and future adaptations.
Sprint Retrospective
A event a the end of the Sprint, lasting at most 3 hours.
It closes the Sprint by having the scrum team reflect on how to improve its ways of working. Is about inspecting and adapting the scrum team itself, focusing on making it more effective and increasing the resulting quality.
This includes increase effectiveness of:
Product Owner
Developers
More info here The Definition of Done ⭐.
It defines what Done means for the increment. It must brings balance between delivering fast and with quality.
At the end of every sprint the team needs to deliver Done increments, and 'Done' might mean different things to different people.
So to ensure visibility, transparency and understanding of what mens for 'work to be done', the scrum team must agree on a Definition of Done.
It is an Anti-pattern that reflects the behavior of teams that focus too much on delivering features as fast as possible while compromising quality.
From a theoretical perspective, Scrum structure is based on the empirical process control theory or empiricism and Lean Thinking.
Simple problems like moving a piece in a chest board are simple, because there are no variables, you can clearly see all the environment and everything is controlled. So you have 100% predictability.
In complex problems, things change, you often know what you want to do, but also know that the path to do that is not linear. You don't know all the variable.
So its like an autonomous car. It has to inspect the environment with its sensors, adapt to changes, and have transparency between its components, so they all can talk together.
Inspect and Adapt
Inspection characterizes the empirical Scrum nature of testing hypothesis.
It is about planning and trying something, checking what happens, learning from it, and adapting. (Also known as PDCA Cycle)
In Scrum, the artifacts and progress toward sprint goals must be frequently inspected.
Whenever a deviation is detected outside the acceptable limits, adjustments must be made to the process itself.
The four formal opportunities for inspection and adaptation:
Sprint planning.
Daily scrum.
Sprint review.
Sprint retrospective.
Transparency
As the name implies, transparency is about having a common standard so that all the observers share a common understanding of what is being seen.
Significant aspects of the process must be visible to those responsible for the outcome.
Its point is to avoid miscommunication.
In scrum this is implemented by having:
Events:
Sprint Planning.
Daily scrum reviews.
Sprint review.
Sprint retrospective.
Also implemented in the Artifacts:
Product Backlog.
Sprint backlog.
The increment.
There are two keyword for this:
Ready:
Is used to describe that product backlog items are clear and detailed enough so that it can be reasonably done within the sprint time-box.
Some teams use the practice of Definition of Ready, which is a list of criteria that tells when a product backlog item is ready. (Not prescribed by the Scrum Guide)
Done:
Is used for everybody to know then a product backlog item or an increment is done.
The Definition of Done ⭐ is prescribed by the Scrum Guide.
Scrum is also based on these 3 pillars.
These values are key to make the scrum pillars come to life, and build the necessary trust between the scrum team and the other stakeholders.
Commitment (1 por todos e todos por 1)
People personally commit, not just get involved to achieving the goals of the scrum team.
Business and technical people must work together.
And the entire scrum team is held accountable for the results.
If one fail, all fail.
Courage
The scrum team members must have courage to do the right thing, and work on tough problems.
You need to get out of your comfort zone.
Its about having a growth mindset.
Focus
Everyone focuses on the work of the Sprint and the goals of the Scrum team.
It is working on what is more important first, that is why the product backlog is emergent and ordered, where usually we have only the top product backlog items with enough details for the developers to understand it and be able to develop it during the Sprint.
Openness
Strongly relates to the Transparency pillar.
The scrum team and stakeholders agree to be open about all the work and challenges with performing the work.
Its about good teamwork, asking and offering help when needed, and sometimes admit that the wrong decision was taken and that the team must change the way of working.
Respect
Scrum team members respect each other to be capable and independent people.
It is about knowing that people are doing their best, giving them autonomy, assuming that they are good enough and have good intentions, recognizing that they have different backgrounds, personalities and abilities.
Respect and Commitment generally are the ones that fail to be followed.
It is the fundamental unit of Scrum.
Usually scrum teams are about 10 people. The roles are not full-time, so team members can have multiple roles.
If a scrum team gets too large, it can be fragmented:
But each team focused on the same product, so they would share the same product goal, product backlog and product owner.
A Scrum Team is self-managed and cross-functional:
Self-Managed:
It has the autonomy to define who does what, when and how.
Cross-Functional:
It is cross-functional as a whole, not the individuals inside the team.
That has all the skills needed to accomplish the work without depending on others not part of the Scrum Team.
This role must be played by ONE person only.
Is the business person, and takes care of the product backlog. He is accountable to maximizing the value of the product resulting from the scrum team.
Must have business knowledge AND authority, AND must be available.
And he does this by managing the product backlog.
In general the PO's job is to analyse the ideas from the Business Stakeholders, and transform them into requests for the developers.
In practice he leads collaborative sessions with the stakeholders, to discuss the product vision and at the end have a motivating short vision. (Be able to explain to explain it in less than 2 min) But they should not act as a filter to accept or deny requests from the stakeholders. The PO should just make sure these request are ORDERED correctly, having the most important ones come first.
Also the PO is NOT the main person responsible to engage with the stakeholder anymore. Now the whole SCRUM TEAM is.
This list of requests is the Product Backlog. The challenge is that the ideias come up way faster that their development.
The PO is NOT a bridge between the Stakeholders and developers. Theses CAN talk to each other if needed, but the Stakeholders CAN'T interfere or command the developers.
Applicable characteristics:
Product Marketplace Expert.
Product value Maximizer.
Product Visionary.
Lear Facilitator of Key Stakeholder Involvement.
His role is to make Scrum run smoothly. The scrum master wears two hats, serving the organization and scrum teams.
He helps those outside the scrum team to interact positively with the team.
Accountable for the scrum team's effectiveness and server it to improve its practices within the scrum framework.
For example:
He assists the PO on how to manage the product backlog to maximize value.
Further, he also coaches the scrum team on how to self-manage and deliver Done and valuable Increments.
Also accountable for establishing scrum, as defined in the scrum guide, by helping everyone understand scrum theory, practices, rules and values.
He also causes the removal of impediments. He does not go looking for impediments to be resolved, he helps resolving them when asked for help.
Anything that might hinder the team's productivity.
Is any kind of problem the developer might have and then they rise these problem to the Scrum Master, usually on the daily scrum.
Are responsible for transforming the ideas reflected in the product backlog into Increments.
Are responsible for tracking the total work remaining in the Sprint Backlog to project the likelihood of achieving the Sprint Goal.
The developers are cross-functional. In other words, the sum of the skills of all the Developers, must be enough to deliver all the aspects of a usable product.
Individuals might have a specialized area of focus, however there are no sub-teams or hierarchies, and they all share the accountability for planning their work and delivering high quality outcomes.
In Scrum if you create any aspect of an Increment, you are a Developer.
Additionally the developers as the entire scrum team, self-manage. They collaborate to solve team problems focusing on team goals and they define who does that, when and how. No one tells them how to do their work.
The developers also must have autonomy on what to work on. For this purpose, during the Spring Planning, or through discussions with the product owner, the Developers select the product backlog items for the sprint.
Only the Developers should decide on removing other developers.
The product owner does not tell the developers what to do.
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.
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.
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.
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.
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:
So considering this, INVEST on your Product Backlog wisely:
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.
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.
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.
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.
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'.
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.
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 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.
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
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.
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.
All the 4 scrum events MUST be executed:
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
They are key to create regularity and minimize the need for meetings not defined in Scrum.
To keep the Scrum Team focused, all the events are time-boxed, and the Scrum Guide prescribes a maximum duration for each one of them.
The team must define their lengths before starting it, which means that they MUST be defined before the Sprint Planning meeting, and it CANNOT be modified.
These events are a formal opportunity to inspect and adapt something, but it does not mean that meetings themselves are formal.
"It is the Heart of Scrum."
Time-boxed to, at most, 1 month, and MUST have fixed duration. They CAN change, but not frequently.
Although, it can be short enough to handle business risks, or to synchronize with other business events. The Sprints help the Scrum Team to control Risks.
During the Sprint:
No changes are made that would endanger the Sprint Goal.
Quality Goals do not decrease.
The Product Backlog is refined as needed.
The Scope may be clarified and re-negotiated with the PO as more is learned.
A Sprint is over only when the time-box elapses, the exception is when the Sprint is canceled.
A Done Increment.
Some done features.
A part of the software that is available to end-users.
Only the PO has the authority to cancel a Sprint.
If part of the work is usable, it is considered Done.
Done backlog items are reviewed.
All incomplete backlog items are re-estimeted and put back in the Product Backlog.
Burn-Up, Burn-Down or Cumulative Flow could be used for the Sprint monitoring.
This event initiates the Sprint, by laying out the work to performed for the Sprint.
When the Scrum Team defines the goal of what to build and the flexible plan to guide achieving it.
The Plan is not fully formulated in the Sprint Planning, it can change.
The Sprint Backlog is the OUTPUT of a Sprint Planning.
For the PO, planning efforts start even before Sprint Planning.
The must a set of Product Backlog Items,
And their mapping to the Product Goal.
Projected capacity of the Developers during the Sprint.
The Definition of Done.
The Product Backlog.
Past performance of the Developers.
The Scrum Team, but they may invite others to attend for advice like:
An invited specialist.
The event has 3 topics to be addressed.
Why is this Sprint valuable? (Craft the Sprint Goal)
It begins with the PO discussing the opportunities for increasing the product's value and utility and how the current Sprint can address it.
As a consequence the whole Scrum Team defines a Goal.
What can be done in this Sprint? (Select the Backlog items)
For this purpose, the Developers select items from the Backlog through discussion with the PO.
Another factor that should be considered, is the Definition of Done, because the more stringent it is, the longer it might take to get Done with each Backlog item.
How will the chosen work get done? (Craft the Sprint Plan)
The developers might use information, such as the upcoming capacity - which is about how many hours available the Developers have for this Sprint.
For instance, will anybody be out of the office during the Sprint?
Like vacations.
Further the Developers could also consider past performance as a reference.
Like seeing how many points were burned in past Sprints.
Since the developers are the ones to turn Backlog items into Increments of Value, they have the final word.
Most Scrum teams, decompose the Backlog items into technical tasks, which are smaller chunks of work often to units of one day or less.
Depending on the area of work, the pipeline will be different, since there will be different tasks.
Usually done by using Scrum Boards, to enable:
Collaboration,
Communication,
Transparency.
Important factors for self-management.
Is a meeting that occurs DAILY, at the same time and place.
Time-boxed to 15min.
The Scrum Master only needs to ensure that the meeting takes place, and is within 15min long. The PO usually does not participate.
Just the Developers MUST attend. Scrum does not forbid others from attending the Daily Scrum, but only the Developers can participate.
Each member answer to usually three questions:
What did I do yesterday that helped the team to meet the Sprint Goal?
What will I do today to help the team meet the Sprint Goal?
Do I see any Impediments that prevents me or the team from meeting the Sprint Goal?
But these are not fixed, the developers can do different. The important thing is that the meeting:
Focuses on assessing the team's progress toward the Sprint Goal, and
Produces an actionable plan for the next day of work.
NOT a technical meeting.
Held at the END of each Sprint. Time-boxed up to 4h.
Its Goal is to:
Inspect the Increment or any other outcome of the Sprint and
If needed, adapt the Product Backlog or determine any other future adaptations.
Have transparency and collaboration between Scrum Team and Stakeholders.
Have the Stakeholder be able to USE the Increment.
Who SHOULD participate:
Users or Customers,
Internal Stakeholders,
Developers,
The Scrum Master,
PO
UNDONE work should NOT be presented in the Sprint Review. Sprint Review is NOT a Demo meeting.
You must NOT present slides,
screenshots,
or similar
It occurs after the Sprint Review. Time-boxed to up to 3h.
Is an opportunity for the Scrum Team to reflect on their methods and teamwork. It is about to make teams better and continuously improving.
The Scrum Master ensures that the event is positive and productive.
The hole Scrum Team SHOULD participate.
Only the Scrum Team participates.
Interpersonal issues?
Product quality issues?
Definition of Done appropriate?
Productivity issues?
Process issues?
Usually have theses questions:
What went well during the Sprint?
What didn't go well?
How can we improve?
Best guided by Nexus Guide, which is a separate Scrum Guide, for scaled scrum.
Means having multiple Scrum Teams working on ONE Product Backlog.
And they work to fulfill the same Product Goal.
ONE PO for all Scrum Teams.
There are multiple Sprint Backlogs each Sprint.
There can be multiple Definitions of Done.
There must be ONE integrated Increment at each Sprint.
Multiple Scrum Master roles which can be occupied by 1 or more Scrum Masters.
The Teams Sprints don't have to be synchronized.
Code can be integrated frequently during the Sprint.
The huge challenge of working with multiple teams is:
DEPENDENCIES.
For this the Nexus, prescribes the Nexus Integration Team. Composed by:
One PO
One Scrum Master
Which might be Scrum Master from Scrum Teams.
And the Nexus integration team
Which might be members from the Scrum Teams.
This team has the role of resolving dependencies and integration issues. Making sure that the entire team is able to deliver the integrated Increment by the end of the Sprint.
This Team is also responsible for defining the Definition of Done, to be applied to the integrated Increment, and this is a MINIMUM.
All Scrum Teams MUST adhere to this Definition of Done.
However this doesn't mean that all Scrum Teams must follow the exactly same Definition of Done, meaning that they can make more stringent definitions, but all have the minimum definition defined by the Integration Team.
It shares the same events as Scrum, with the exception that the:
Nexus Sprint Planning
Nexus Daily Scrums
Nexus Sprint Retrospective
Complements their "Scrum Versions", with the main goal of handling dependencies between the Scrum Teams.
And the:
Nexus Sprint Review
Replaces the "Scrum Sprint Review".
Define the Product Vision.
The PO will discuss with the stakeholders to define a product vision, that is clear and short.
The Scrum Master will help maintain this meeting as productive as possible.
Define the Product Strategy, which is how is the Product Vision be achieved.
Part of this is defining one or more Product Goals.
They are manifestations of the Product Strategy.
They are keys for giving the Scrum Team a concrete strategy on what it needs to build to deliver a valuable product.
The PO and entire Scrum Team should be evolved with Stakeholders to come up with the Product Goals.
Defining the Product Backlog.
Detailing everything necessary for the product, but with the right level of details. just-in-time
Meaning that we will detail just enough items for the upcoming Sprint.
In the beginning all the items will be EPICS, an then will be refined to be more concise and specific.
Refinement can be done with User Stories this means:
Writing a Card which is a description of the functionality, valuable to a user or customer. Must be written from the perspective of a customer or user.
As [actor], I want [action] so that `[end].
Conversing, which represents the collaboration between the PO, the business people and Developers.
Confirming, which is a list of criteria that the Scrum Team will define to serve as verification if the product delivered suits the needs.
List of criteria that must be satisfied. (Just like Test Cases)
After creating the items, we now need to order them. Could be done ordering by:
Return on Investiment (ROI)
Value
How much value it will deliver.
Size
How much work has to be done the deliver this item.
Is it fast or slow.
The ROI takes both into consideration by .
Risk
A riskier User Story is the one that depends on things that the Scrum Team is not familiar with.
And they should have higher priority, since if they don't work, less waste will have been produced.
Dependencies
The dependencies between User Stories must be also considered.
If a higher ROI item depends on a lower ROI one, the lower one will still have to be done before.
Define the business value using Kano.
How can infer the value of User Stories?
With the Kano Model:
Classify the Backlog items in:
Mandatory. (Higher priority) (All of them must be at the Backlog)
Linear. (Medium priority)
Exciter. (Less priority) (Should have a few)
But, to be able to order we first need to be able to estimate the values:
This will be done with Story Points and Planning Poker.
Story Point will be in a scale of: 1, 2, 3, 5, 8, 13, 20, 40, 100.
It is a team metric.
The estimation itself will be done with Planning Poker.
A collaborative consensus based agile estimating technique.
For the first time, you will select the smallest and easiest User Story, and give it a Story Point of 2. The other ones will then be relative to this one.
Construct the Definition of Done:
Sets of Criteria like:
Quality assurance
Architecture
Non-functional requirements
Process management
Configuration management
You can also define Done in different levels:
Task
Product Backlog Item
Sprint (Increment)
Release
Project
Form the Scrum Team, considering: - Hard skills: (There must be redundancy here - multiple devs with same circle of knowledge - otherwise they cannot help each other) - Technical Factors: - Knowledge about methodologies, - Processes, - Technologies, - Tools - Soft skills: (How well they work as a team) - Social Factors. - How good is their communication. - Personality. - Interpersonal Abilities. - Individual Costs. - You can bring all the candidates members together and let them organize into Scrum Teams. - Or make existing teams propose the new Scrum Team.
Now you develop a Release Plan to bring alignment with the team and choose the Backlog items to be in the release.
It can be built with a Feature-based approach:
Fixed Scope, but let Time flexible.
Select a set of Project Backlog items and plan how to deliver them.
Or can be built with a Date-driven approach:
Fixed deadline, flexible scope.
Now you can estimate how many sprints it will take to burn all the Story Points to get this release done.
You will create the Best and Worst case scenarios, discussed in the Cone of Uncertainty.
You can use historical data, on how many points usually the team can burn in 1 Sprint.
Otherwise you will have to predict the velocity:
By analyzing a Backlog Item, an how many hours it would take to complete it.
You must consider that the team wont have 100% effectiveness, it will be from 55% to 80%.
So if they in total work 100 NOMINAL hours per week, they will in practice work only 55 to 80 REAL hours.
If this Backlog item has 10 points, and the team can complete it in the Sprint in 50 hours, then it will take them 5 hours/print.
Thus they would be able to burn in a Sprint to points.
The Release Plan must be updated at the end of every Sprint, in the Sprint Review.
You never decide the Sprint Length after you pick the User stories for the Sprint.
Refining the Product Backlog items can happen:
During the Sprint Planing.
Or by having a separate Refining Meeting.
In the Sprint Planning:
Must Address:
Why is this Sprint valuable?
Discuss the opportunities to increase the products value and utility.
How this can address this.
Scrum Team defines a Sprint Goal:
It communicates why the Sprint is valuable to all stakeholders, brings transparency.
Sprint Goals should not be defined after selecting the Backlog items.
What can be Done this Sprint?
Break down EPICS into smaller User Stories.
Define how much can be completed during the Sprint:
See upcoming capacity:
How many hours available the Devs have for this Sprint.
If anyone will be off the office.
Could consider past performance or consider the Team Velocity.
How will chosen work get Done? (The Plan)
Create the Sprint Backlog and the Plan:
Decomposing the Product Backlog Items
Team can design a sketch of the solution, to have an overview of what needs to be done.
After decomposing and learning more, you gather and check if more can be included, if things need to be removed, always thinking in the Sprint Goal.
Then you have a Sprint Backlog.
After the Sprint Planning is finished:
ONLY the developers can change the Sprint Backlog.
And the Sprint Backlog is the ONLY source of work for them.
The Sprint is when the done usable potentially releasable product increment is created.
Developers should not be interrupted with demands that are not focused on the Sprint Goal.
During the Sprint in Software Development this is executed:
Requirements
Architecture
Design
Implementation
Testing
Unit Testing
Integration Testing
System Testing
Ideally, the Scrum team does all the work necessary to deliver the product.
But in some cases, part of the work will be done by external team.
The Daily Scrums:
The developers don't plan only in the Sprint Planning, they also plan daily with the Daily Scrums.
To talk about their progress and synchronize work.
Each one must answer:
What did I do since last meeting? (Can be ignored, to only discuss the future)
What will I do until next meeting?
Do I have any Impediments?
Tips on Daily Scrum:
Don't share shallow information.
Don't discuss technicalities.
Sprint Burndown are usually done in the Daily Scrums.
6 indicators of bad Daily Scrums:
Team members are reporting status to Scrum Master or PO.
Some members arrive late.
Taking more than 15 minutes.
People share shallow information.
Some members don't pay attention to what others say.
Scrum Master or PO manage turns.
When the Sprint is almost over, an everything is almost Done, the Team could refine some Product Backlog Items for the next Sprint.
IF there are disturbances in the Sprint, you cannot blindly follow the Scrum rules. - You might have to cease a bit if necessary depending on the case.
What to do with Product Backlog items that are not Done by the end of the Sprint?
The incomplete items are moved back to the Product Backlog.
The Sprint Review (The goal is to inspect the Increment and adapt the Product Backlog if needed)
The developers will check which Backlog items are Done.
And prepare them to be demonstrated in the Review.
Inspection:
After getting the feedback from the users and stakeholders.
The Scrum Team will discuss the Product backlog.
Given the release plan, the PO might discuss the likely target and delivery dates, by using the Release Burndown chart.
Product Backlog Grooming:
Usually the grooming is not done in the Review, since it takes a lot of time, and the review should be used to rise these feedbacks.
These can be part of the Backlog Refinement Sessions on Sprint Planning.
Or in separated Workshops after the Sprint Planning.
The PO doesn't need to wait until the Sprint review to inspect and give feedback to the developers on what has been done.
Don't rely only in the Sprint Review to get feedback from Users and Customers.
The Sprint Retrospective
Avoid using the same methods in the Sprint Retrospective.
Questions to be anwsered:
What went well during the Sprint?
What didn't go well?
How can we improve?
5 steps of the meeting:
Setting the stage.
Welcome people and reiterate how important the meeting is.
Review the Improvement List.
Presente meeting structure.
Gather data.
Gather all that happened, for good or bad during the Sprint.
Generate insights.
Improvement Points.
Lessons Learned.
Decide what to do.
Which actions will be put for next Sprint.
The most impactful improvements are addressed as soon as possible.
The may even be added to the Sprint Backlog for the next Sprint.
Treat improvement items as backlog items:
Retrospective Planning Poker.
Close the meeting.
Its goal is to handle requests as efficiently as possible.
Scrum and Kanban can work well together.
Make the workflow visible, the process visible.
Using the Kanban board.
Defining explicit limits about how many items can we have at a state at the same time.
Limiting the work in progress.
Measure the lead time.
Lead time measures the period from when a request is created or a ticket arrives, to when it is fulfilled.
What needs to be done.
(The "What" dimension)
How to do it.
(The "How" dimension)
Security
Reliability
Performance
Maintainability
Scalability
Usability
Detailed
Consider dependencies.
Estimated
Insurance against risks.
Emergent (It Evolves)
Value, could be inferred with Kano for instance.
(P)Ordered
Estimated effort, using Story Points.
(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)
