Scrum is an Agile framework within which teams can address complex problems and deliver value through complex products. It is well-known for being a lightweight framework that helps individuals, teams, and organisations create value through adaptive solutions.
Scrum was created by Ken Schwaber and Jeff Sutherland.
In summary, Scrum requires a person in the role of Scrum Master to create a delivery environment where:
1. A person in the role of Product Owner is responsible for ordering a Product Backlog.
2. A Scrum Team creates an increment (based on a subsection of the Product Backlog) of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results of the Sprint and adapt to the next Sprint.
Scrum Events (or Scrum Ceremonies) are defined to “inspect and adapt” the overall Sprint activities. All Scrum Events are time-boxed. Below are the four Scrum events:
Sprint Planning: This event is time-boxed at 4 hours for a two-week Sprint and 8 hours for a four-week Sprint. This Scrum event happens at the start of a Sprint where the team identifies the Product Backlog items to work on in the upcoming sprint.
For more information about Sprint Planning, click here.
Daily Scrum: This event is also sometimes known as the Daily Standup. It is a 15-minute time-boxed event (regardless of the length of Sprint). The Developers discuss progress towards the Sprint goal, any impediments and synchronise their daily work activities. They plan their work until the next Daily Scrum.
For more information about the Daily Scrum, click here.
Sprint Review: The Sprint Review is time-boxed at 2 hours for a two-week Sprint and 4 hours for a four-week Sprint. This event happens at the end of the Sprint. This is the feedback event where the Developers give a demo of the work in the Sprint, and the Scrum Team and the other stakeholders inspect the increment. The team considers if any if any changes are needed and adds them to the Product Backlog for future deliveries.
For more information about the Sprint Review, click here.
Sprint Retrospective: This event happens immediately after the Sprint Review and it is time-boxed at 1.5 hours for a two-week Sprint (and 3 hours for a four-week Sprint). This helps Scrum Teams to reflect upon their deliveries in the Sprint and identify any opportunities for improvement and plan for it in the next or future Sprints.
For more information about the Sprint Retrospective, click here.
The Sprint: The Sprint itself, a wrapper for all the other Scrum events, is also considered an event.
Sprints are iterative, short interval, fixed time-boxed periods where a Scrum Team accomplishes the Sprint goal by completing a defined set of work, and customers and stakeholders get the sense of the Product as it grows incrementally. The incremental delivery of work from Sprints ensures that the Product development goes through “inspect and adapt” cycles frequently and effectively, and helps the Scrum Team successfully achieve the overall Product vision.
Scrum has three defined roles for the Scrum Team. They are the Product Owner, Scrum Master and the Developers. While the Product Owner focuses on “what” needs to be delivered, the Scrum Master facilitates through the Scrum events and the Developers decide on “how” to deliver the Product Increment. These roles are defined clearly than traditional job titles.
To know more about Scrum Roles, click here.
Agile Scrum artifacts help to establish the “transparency” within the Agile Scrum process. Artifacts are the information available for the Scrum Team and stakeholders to understand the details of the software product being developed, and the steps taken to deliver the project. These artifacts provide deep insights into performing the Scrum Team with the necessary metrics. The Scrum artifacts are: Product Backlog, Sprint Backlog, and Product Increment.
To know more about the Agile Scrum Artifacts, click here.
Sprint cycles are developmental cycles that are iterative and repeat until the final product is complete and delivered. Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective are the set of processes repeated in each Sprint. Within each sprint, the user stories (requirements) are reviewed and prioritised, developed, tested, and signed-off. One sprint cycle usually takes up to 2 to 4 weeks.
The Scrum framework is based upon the core Scrum Values: Commitment, Focus, Openness, Respect, and Courage. The Scrum Values support the three pillars of the Scrum that are Transparency, Inspection, and Adaptation for ensuring that there are trust and collaboration among the team.
Commitment: The Scrum Team commits to project objectives and work. The individuals in the team are accountable for their deliveries.
Focus: When the Scrum Team members stay focused on their delivery, the Sprint goal is achieved without deviation. The Scrum Master ensures there is no external pressure or influence that will affect the team’s focus and wastage of resources. A focused Team can deliver the work with good quality and be productive.
Openness: The Openness in a Scrum Team promotes transparency and builds trust. Teams are clear on what their end goals are and can decide on their own according to the need when the process is transparent and highly visible. All the supporting systems can help each other and learn from each other and grow in such a fair working environment. Team members can share their feedback openly and can receive it from others.
Respect: The Scrum Team members should respect each other’s viewpoint irrespective of experience, skills, knowledge, position, etc in the organisation. This factor helps the team members to collaborate better and make decisions effectively for delivering successful projects.
Courage: Courage is to say “no” to the things which shouldn’t be done and also accepting a change. This is an important attribute of an Agile Team to embrace that will help to tackle risks and think of better solutions.
Scrum uses an Empirical process control (or Empiricism) to adapt to the changing requirements of the customer. It drives from experience-based knowledge by inspecting and adapting to the required changes in the course of execution of a project. The three pillars of Scrum that uphold every implementation of empirical process control are: Transparency, Inspection, and Adaptation.
Transparency: The Scrum artifacts and events such as Product Backlog, Sprint Backlog, Task Boards, Burn-down and Burnup charts, Daily Scrum, Sprint Review, Sprint Retrospectives, Definition of Ready, Definition of Done, etc, that helps in adding visibility of the work and team activities to all the stakeholders. This helps in achieving the product goal, appreciate efforts, and synchronise the teams if there are any deviations.
Inspection: Scrum artifacts have to be frequently visited and inspected to see through the progress and identify if there are any variances in achieving the goal. Ordered Product Backlog items, Sprint Backlog items, Scrum Task board, charts are used by the stakeholders to understand the current state of the project. Sprint review helps in getting feedbacks and retrospective meeting helps in identifying key improvement points and adapting them.
Adaptation: In Agile, when there is a need to embrace changes, we adapt and strive for improvement. Scrum events emphasise that and facilitate keeping an eye on improvements and adapting them to get things done better. In fact, Agile processes constantly encourage experimenting, and if undesired variances are identified then make the necessary adjustments to minimise further deviation.
DOR is the abbreviation of “Definition of Ready” which is a checklist or agreement that helps the developers to start the work when all the required criteria are met.
Also, read “Definition of Ready”.
The Definition of Ready (DOR) is a checklist that is agreed upon by the Scrum Team and lets all the stakeholders know when the Sprint backlog items are ready to begin.
For example, when a user story is ready to be added to a Sprint backlog with all the acceptance criteria defined and to start the work immediately. The Team knows what needs to be done and the amount of effort is required to complete the work.
The DOD is the abbreviation of “Definition of Done” which is an agreed checklist necessary to say the backlog items are “done” fully for the product increment.
Also, read “Definition of Done”.
The “Definition of Done” is a set of criteria defined to mark the product backlog items “done” at the end of the sprint. For example, An user story must meet all its acceptance criteria, code reviews have to be passed, code has been tested and signed off, etc. This helps the team to push the work items to product increment, and the team is ready to move to the next sprint.
Release planning is a high-level planning process to decide on the date, scope, budget, schedule, milestones, sprints (three to twelve iterations) for incremental deliveries, etc. Usually an initial release planning is done after the product planning.
This release planning gives a vision of the product roadmap on what can be built in the release against when the release will be available. Further, this helps in deciding the number of product backlog items can be delivered against the features planned for the release.
Burn-down charts can be applied to any Agile project delivery that helps to understand the progress of the sprint over time.
A burn-down chart shows the graphical insights of the amount of work that has been completed in a Sprint and the total remaining work. It represents the total amount of work and then depicts the amount remaining over time. The graph also helps in predicting when the team can complete their work and if there are any likelihood of variances in the delivery plan.
A burn up chart is a visual graph used on Agile projects and a popular project management tool for visually tracking and measuring progress, and better at illustrating the work that has been accomplished by the team. The burn up chart shows the amount of work completed in a sprint compared with its total scope of work.
User stories in simple terms are typically the user requirements written in short sentences that help to focus on one particular aspect of the requirement.
Click here to know more about user stories.
By definition, Acceptance Criteria is a set of conditions/statements that a software product must satisfy before it is accepted by a user, customer or other stakeholders. Acceptance Criteria is written against a User Story that specifies conditions under which it is satisfied and can be accepted that it completes the User Story.
Relative estimation is one of the flavours of estimation used in Agile Teams that consists of estimating the work by size first by relatively comparing it with the previously completed task of similar size. There are several estimation techniques available for relative sizing of the user stories namely: Ideal time, Story points, T-Shirt sizing, etc.
Story points are used as a unit of measure for deriving the effort estimates to complete the user story in terms of relative sizing. A story point is assigned to the work item. For example, if you assign 2 as story point then it means the size of the story is twice that of the story that is assigned with a one story point.
In agile development, work in progress (WIP) limits refer to the maximum amount of work that can be accomplished in each status of a workflow. This limiting factor helps in identifying inefficiencies, thereby limiting the amount of work in progress at any given point in time. This helps in avoiding unnecessary burnout of work in the team.
A good user story will satisfy the three elements that are referred to as the three C’s (as proposed by Ron Jeffries): Card, Conversation, and Confirmation.
For more information about 3Cs of User Story writing, click here.
The Scrum Sprints are short cycles for faster delivery of business value to the customers. The scrum guide also suggests that a Sprint not be longer than one month. A minimum viable product or a minimum marketable feature is released to the client in shorter sprints. Usually, a sprint spans between two to four weeks. This shorter duration helps the Scrum Teams identify the risks and issues quickly and can remove the impediments and blockers at the earliest.
A Sprint zero is not a recognised practise in Scrum. However, Sprint zero usually takes place before the formal start of the project/sprints. It is a preparatory phase that allows teams to create all the necessary things before the start of the actual sprint like creating/updating the product backlog, prototyping, setting up the infrastructure and necessary software/tools, architectural planning, fulfilling the training needs, and preparing test plans, etc.
In agile software development, a Spike Story is a special type of user story created when there is more insight is required before starting the actual work such as researching, deciding on evaluating a technology, assessing the technical feasibility, doing a proof of concept (POC), etc. Since the approach is unclear at this stage, the spike stories cannot be estimated as like a user story. But a certain number of hours are allocated for the work during the sprint and the team would spend the allocated time only for this Spike story.
Also, Spike Stories are created for the work visibility and the output of this may eventually turn into a user story subsequent sprints. They are not direct requirements from the user, but they are required to make a decision way forward in the project development and delivery. Spike stories can be Technical Spike Stories (for technical feasibility) or Functional Spike Stories (evaluating a functionality or the usability through prototyping, wireframes, etc, and get customer or stakeholders feedback).
Scrum of Scrums is a scaled agile time-boxed event that provides an opportunity for multiple Scrum Teams to connect and work together to deliver a complex solution. This doesn’t replace the Daily Scrum meeting within the individual teams. However, a representative from each Scrum Team attends this event and shares their high-level updates on work progress, discusses any impediments or blockers in their way to take it to resolution.
Distributed Scrum teams are also referred to as remote teams or virtual teams. They are not co-located in one office but distributed across geographical locations but working on the same project and collaborating to achieve the project goals. While the teams are distributed, still they adopt scrum practices like scrum events, maintaining artifacts, sharing, and collaborating at work using tools and technologies as if the teams are located in the same place and delivering the project in sprint cycles.
There are lots of advantages to having the distributed Scrum Teams because it adds productivity, people from different skill sets can learn from each other, learn the best practices from other locations and adapt them. Additional work location helps in case of an unforeseen event such as a natural disaster happens in one city, the business can still run without much impact from other locations. Scaling up the team with skillful people becomes easier due to market conditions and the availability of distributed locations.
MVP is the abbreviation of Minimum Viable Product. MVP is the bare minimum requirement/features to be built and showcase it to the stakeholders and customers that are ready for shipment.
Time box is a fixed unit of time allocated for an activity. All Scrum events are time boxed. Time boxing is the maximum length of time within which the Scrum event has to take place.
Sashimi is a Japanese word for a dish, and it means a pierced body in which fish or meat is sliced into thin pieces where each piece tastes similarly compared to other slices. In the Scrum context, organising every phase of the product development in a sprint that is completed after a product is displayed. The phases include requirement analysis, planning, design, coding, testing, documentation, etc.
Waterfall methodology of product development is more suitable over Scrum where the requirements are well defined, predictable, and clearly understood.
A Scrumban is a software development model comprises both Scrum and Kanban frameworks. It is helpful in projects where it requires continuous effort in maintenance, defect fixing, etc, and to be completed in a minimum time.
Three amigos refers to the three roles that come together to validate the product before an increment of work. They are Business Analyst (business requirements), developers (low-level design of the system), and testers (test cases). The purpose of the Amigos meeting is to bridge the gap in understanding of the business specifications by three Amigos.
The Scrum team should be smaller in size so that the complexity of team communication is better. The ideal size of the Scrum Team as prescribed by the Scrum guide is 7 to 9 members with +/- 2 members.
In Scrum context, an impediment is a blockage that affects the team productivity and slows down the work progress in a Sprint.
The developers usually review and remove their roadblocks. In case if they need help, Product Owner or the Scrum Master will assist them in removing the impediments. The impediments may arise due to some of these reasons:
– Organisational changes
– Technical/Infrastructure issues
– Inadequate skills/new technology
– Stakeholder/Business decisions
The Product Owner alone has the authority to cancel the Sprint. Although this is not a usual case, the Sprint can be canceled when the Sprint goal becomes obsolete. The Sprint is cancelled before the Sprint cycle is over. The Product Owner may be influenced to take the step of canceling the Sprint by the stakeholders or Scrum Team.
Since the work items may have been in completed state, the “Done” items are reviewed with Product Owner if they are releasable. The incomplete items are put back on the Product Backlog so that when the future Sprint kicks off, it will be in a proper state for the teams to work through the Product Backlog list.
Given-When-Then is the template used to represent the Acceptance criteria (tests) for a User Story. It is part of the Behaviour Driven Development and they refer to: (Given) Pre-condition context or criteria, (When) action performed, (Then) expected consequences. This structure is used to write the business use cases from the customer point of view; the focus is on customers who interact with the product.
There is no restriction or guideline that one person with a particular role can write the user stories. Anyone can write user stories. However, the product owner has the ownership and responsibility to make sure a user story is created against the Product Backlog requirement, which can be written by any team member.
‘Kaizen’ is a Japanese word that means “good change” (Kai = change, Zen = good). Kaizen refers to the continuous improvement of all business functions, at all levels in the organisation. The teams work to create a culture of continuous improvement in their work practices. It is a long-term Scrum approach where all employees work together to achieve results through frequent deliveries and incremental changes in order to improve throughput and quality.