# SCRUM
We use this framework on all of our projects, The goal is to be adaptive to complex problems while productively and creatively delivering products with the highest possible value. There are Roles, events and artifacts. Check out The Scrum Guide
# Pillars
Knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.
Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation
# Transparency
Process must be visible through a common standard so the team share a common understanding about the Definition of Done
# Inspection
Scrum TeaM must inspect artifacts and progress towards a Sprint Goal to detect undesirable variances.
# Adaptation
If there are undesirable aspects the process must be adjusted. This should be made ASAP to minimize further deviation
Scrum Prescribes 4 formal events for inspection and adaptation:
- π Sprint Planning
- π Daily Scrum
- π₯ Sprint Review
- π©ββοΈ Sprint Retrospective
# Values
When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.
The Scrum Team members learn and explore those values as they work with the Scrum roles, events, and artifacts
- Successful use of Scrum depends on people becoming more proficient in living these five values.
- People personally commit to achieving the goals of the Scrum Team.
- The Scrum Team members have courage to do the right thing and work on tough problems.
- Everyone focuses on the work of the Sprint and the goals of the Scrum Team.
- Scrum Team members respect each other to be capable, independent people.
# Roles
The Scrum Teams are self-organizing to choose how best to acomplish their work and cross-functional to have all competencies.
# π©βπ» The Product Owner
Is responsible for maximizing the value of the product resulting from work of the Development Team. The following responsibilities could be shared with the Scrum Team.
- Clearly expressing Product Backlog items
- Ordering the items in the Product Backlog to best achieve goals and missions
# π©βπ§ The Development Team
Professionals who do the work that delivers the increment capable of organizing and managing their own work.
- They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.
- Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment
- Individual Development Team members may have specialized skills, but accountability belongs to the Development Team as a whole
# π©βπ The Scrum Master
Is responsible for promoting and supporting Scrum by helping everyone understand theory, practices, rules and values with the goal of maximize value.
# Service to the Product Owner
- Ensuring goals, scope and product domain are understood by everyone.
- Finding techniques for effective Product Backlog management.
- Helping the Scrum Team understand the need for clear and concise Product Backlog items.
- Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.
- Understanding and practicing agility. and Facilitating Scrum events as requested or needed.
# Service to the Development Team
- Coaching the Development Team in self-organization and cross-functionality.
- Helping the Development Team to create high-value products.
- Removing impediments to the Development Teamβs progress.
- Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood and Facilitating Scrum events as requested or needed
# Service to the Organization
- Leading and coaching the organization in its Scrum adoption.
- Planning Scrum implementations within the organization.
- Causing change that increases the productivity of the Scrum Team.
# Events
All of these are time boxed events with a maximum duration. Once Sprint begins, its duration is fixed and cannot be shortened.
These events are designed to enable critical transparency and inspection.
# πββοΈ Sprint
This is the heart of Scrum of 1 month or less during an increment is created.
- No changes are made that would endanger the Sprint Goal.
- Scope may be clarified and re-negotiated between the Product Owner and Development Team.
Each sprint is considered a project with a goal resultant in the product increment
# π Sprint Planning
The work to be done in the sprint answering:
# What can be delivered in the Increment resulting from the upcoming Sprint?
Taking the Product Backlog as an input, the latest product increment, the team velocity and previous performance of the team. The number of items is defined by the Development Team.
The Sprint Goal is the objective that will be the focus of the Sprint as it represents the increment
# How will the work needed to deliver the Increment be achieved?
Having set the Sprint Goal The Development Team self-organizes to undertake the work in the Sprint Backlog.Development
If the Development Team determines that it has too much or too little work, it may renegotiate the selected product backlog items with the Product Owner.
By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.
# π― Sprint Goal
Is the objective
# π Daily Stand Up Meeting
While the Sprint is in progress the Team and the Scrum Master (Project Manager) must have a Daily Stand Up Meeting, each member has 5-15 minutes to communicate to rest of the team the following questions:
- What did you do yesterday?
- What will you do today?
- Are there any impediments in your way?
By focusing on what each person accomplished yesterday and will accomplish today, the team gains an excellent understanding of what work has been done and what work remains. The daily scrum meeting is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other.
# π©ββοΈ Sprint Retrospective
The opportunity for the Scrum TeaM to inspect itself and create a plan of improvements for the next spring.
- Inspect how the last Sprint went with regards to people, relationships, process, and tools.
- Identify and order the major items that went well and potential improvements.
- Create a plan for implementing improvements to the way the Scrum Team does its work.
No matter how good a Scrum team is, there is always an opportunity to improve.
By the end, the Scrum Team identified improvements that it will implement in the next Sprint, enforcing to focus on inspection and adaptation for continuous improvement.
# π₯ Sprint Review
At the end of the Sprint we do this to inspect the Increment and adapt the Product Backlog. The Scrum Team and stakeholders collaborate about what was done in the Sprint. Attendees collaborate on the next things that could be done to optimize value. The presentation of the Increment is intended to elicit feedback and foster collaboration.
Attendees include the Scrum Team and key stakeholders invited by the Product Owner.
The Product Owner explains what Product Backlog items have been βDoneβ and what has not been βDoneβ.
The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved.
The Development Team demonstrates the work that it has βDoneβ and answers questions about the Increment.
The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed).
The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning.
Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next.
Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
# Artifacts
# π Product Backlog
Is an ordered list of everything that is known to be needed in the product created by the Product Owner.
The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.
Product Backlog items have the attributes of a `description, order, estimate, and value and test descriptions that will prove its completeness when βDone.β
# π Product Backlog Refinement
Is the act of adding detail, estimates, and order to items in the Product Backlog.
This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.
The Scrum Team decides how and when refinement is done.
Refinement usually consumes no more than 10% of the capacity of the Development Team.
Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail.
# π Sprint BackLog
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.
To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.
The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.
# π Increment
Is the sum of all the Product Backlog items completed during a Sprint.
At the end of a Sprint, the new Increment must be βDone".
The increment is a step toward a vision or goal.
# Artifact Transparency
Is the basis of scrum. Decisions to optimize value and control risk are made based on the perceived state of the artifacts.
The Scrum Masterβs job is to work involves learning, convincing, and change. Transparency doesnβt occur overnight, but is a path.
# β Definition of "Done"
Everyone must understand what βDoneβ means to ensure transparency about reaching the increment.
Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.
# Status *
The task status is one of the keys to keep the transparency pillar.
# NOT STARTED
# π Open
Initial state of every tasks, this tasks could be done in the Sprint Sprint BackLog or not and transferred to the Product/TeaM Backlog
# π SPRINT BACKLOG
This is a to-do task that needs to be completed in the current Sprint
# ACTIVE
# π¨βπ» IN PROGRESS
The assigned person use this label to share that work has begun
# π REJECTED
The supervisor/tester/project manager use this to indicate that it did not passed the QA process. The assigned person must solve the issues/enhancements commented.
# π BLOCKED
The assigned person use this to indicate that needs assistance because is blocked and cannot continue
# DONE
# βοΈ COMPLETED
The assigned person use this label to indicate the work is done and is ready for tests/review (QA process)
# π©βπ¬ IN REVIEW
The supervisor/tester/project manager use this label to indicate that is working on review the task to accept or reject
# π ACCEPTED
The supervisor/tester/project manager use this to indicate that the tests passed. In case of development tasks, this label indicates is ready to go to production.
# CLOSED STATUS
# β DONE
Itβs used to indicate the completion, In development that it was deployed
# Poker Planning *
PLUSTEAM use planningpoker to do the Poker Planning with the SCRUM Deck:
- <1h: Less than 1 hour
- 1h: 1 hour
- 2h: 2 hour
- 3h: 3 hour
- 5h: 5 hour
- 8h: 8 hours or 1 Work Day
- 13h: 13 hours
- 20h: 20 hours
- 40h: 40 hours or 1 Work Week
- 100h: 100 hours, Too much
- ?: Don't have an idea
- βοΈ: Infinite time
# Sprint Naming
Gitlab Community edition is a good example, in their documentation they recommend Agile sprints time frames like 2019 M1 W1, 2019 M1 W2, ...
Our standard is:
- Due to ClickUp Limitation We use the name of the TeaM, and sometimes the project first
- The deadline for the sprint
Develop 1 - Jul 15 Develop 2 - Jul 31 Develop 3 - Aug 15
# References
*: Not a default element from SCRUM, Our custom approach
β Project Management Asana β