Scrum is a framework for project management that emphasizes teamwork, accountability and iterative progress toward a well-defined goal. The framework begins with a simple premise: Start with what can be seen or known. After that, track the progress and tweak as necessary.
Three pillars of Scrum
The base of Scrum is Empiricism, which states that knowledge comes from experience and we should make decisions from what is known. There are the three pillars that hold Scrum together.
Best Scrum Software Every Project Needs
A powerful scrum software that supports scrum project management. It features scrum tools like user story map, product backlog management, sprint backlog management, task management, daily scrum meeting, sprint planning tool, sprint review tool, sprint retrospective tool, burndown, impediment, stakeholder and team management.
Scrum delivers features at a time, while waterfall simply delivers phases. A typical waterfall style development is phased-based and sequential process that will not give value until the very end the project. Scrum turns that model on its head and delivers new features every few weeks instead of focusing on a big release in the future.
Scrum divides complex work into simple pieces, large organizations into small teams and far-reaching projects into a series of short time horizons called sprints.
By building iteratively and incrementally, companies are able to deliver customers the products and services they really need faster and more effectively. With Scrum, you can receive and incorporate customer feedback at the end of every small development cycles, which means your results get shaped by real-world use, not your assumptions. This makes it much easier to keep customers and key stakeholders closely involved and engaged.
Agile vs Scrum
Agile methodology is a practice that helps continuous iteration of development and testing in the SDLC process. Agile breaks the product into smaller builds. Scrum is just one of the many iterative and incremental agile software development process that allows us to focus on delivering the business value in the shortest time.
The Scrum Framework usually deals with the fact that the requirements are likely to change or most of the time not known at the start of the project. The Characteristics of Scrum are:
Simple to understand
Difficult to master
Benefits of Scrum
Following are the benefits that scrum provides to organizations, teams, products, and individuals.
Better Quality: Projects exist to accomplish a vision or goal. Scrum provides the framework for continual feedback and exposure to make sure that quality is as high as possible. Scrum helps ensure quality by the following practices
Reduced time to market: Scrum has been proven to deliver value to the end customer 30 to 40 percent faster than traditional methods.
Increase Return on Investment: The decrease in time to market is one key reason that scrum projects realize a higher return on investment (ROI). Because revenue and other targeted benefits start coming in sooner, earlier accumulation means higher total return over time. This is a basic tenet of net present value (NPV) calculations.
Higher Team Morale: Working with happy people who enjoy their jobs can be satisfying and rewarding. Self-management puts decisions that would normally be made by a manager or the organization into scrum team members’ hands.
Enhance Team Collaboration: When scrum teams take responsibility for projects and products, they can produce great results. Scrum teams collaborate and take ownership of quality and project performance through enhanced team participation and communication.
The Scrum Framework
Scrum is simple. It is the opposite of a big collection of interwoven mandatory components. Scrum is not a methodology. Scrum implements the scientific method of empiricism. Scrum replaces a programmed algorithmic approach with a heuristic one, with respect for people and self-organization to deal with unpredictability and solving complex problems. The below graphic represents Scrum in Action as described by Ken Schwaber and Jeff Sutherland in their book Software in 30 Days taking us from planning through software delivery.
The components of Scrum process
The Scrum Framework itself is very simple. It defines only some general guidelines with only a few rules, roles, artifacts and events. Nevertheless each of these components is important, serves a specific purpose and is essential for a successful usage of the framework.
When an organization decides to embrace Scrum, one of the first things to understand is how Scrum roles differ from traditional project execution roles. While there are only three main roles in Scrum, they don’t automatically align with titles familiar to most of us. Let’s start with a brief definition of each:
Product owner is a scrum development role for a person who represents the business or user community and is responsible for working with the user group to determine what features will be in the product release. The main responsibilities of the Product Owner are:
Develop the direction and strategy for the products and services, including the short and long-time goals;
Provide or have access to knowledge about the product or the service;
Understand and explain customer needs for the Development team;
Gather, prioritize and manage the product or service requirements;
Take over any responsibilities related to the product or service budget, including its profitability;
Determine the release date for the product or service features;
Work together with the development team on a daily basis to answer questions and take decisions;
Accept or reject completed features related to the Sprints;
Show the main realizations of the development team in the end of each Sprint;
Responsible for the Product Backlog
A scrum master is the facilitator for an agile development team. Scrum is a methodology that allows a team to self-organize and make changes quickly, in accordance with agile principles. The scrum master manages the process for how information is exchanged. The main responsibilities of the Scrum Master are:
Act as a coach, helping the team to follow scrum values and practices;
Help to remove impediments and protect the team from external interferences;
Promote a good cooperation between the team and stakeholders;
Facilitate common sense within the team;
Protect the team from organization distractions;
Scrum team (aka. Development team) is formed with from 3 to 9 people who MUST fulfill all technical needs to deliver the product or the service. They will be guided directly by the Scrum Master, but they will not be directly managed. They must be self-organized, versatile, and responsible enough to complete all required tasks.
The development team is responsible for delivering potentially shippable product increments every sprint from analysis, design, development, testing, to technical writing and etc. It is extremely important for Scrum team possesses the following characteristics:
Teams must be Self-Organized. All team components must manage their own efforts to complete the assignment that has been given. In Agile Scrum there is no figure of the Team Leader or Line Manager. Everybody must be committed enough to perform their own activities and contribute to the success of the team. If one fails, everybody fails.
Teams must be Cross-functional. All team members together must possess all required knowledge and skills to deliver a service or product that is well done and ready to use. A specialist can be used in necessary cases, but only as a coach who transfers the knowledge to the team to fulfill a specific gap.
Being a Product Owner Requires a Business Vision. The Product Owner represents the voice of the customer and needs to translate their needs to the Scrum Master and Development Teams. This is usually a full-time job.
The Scrum Master is not a Line Manager. They help to provide the required coach to the Development team and also help to remove any barrier that the team faces.
The SCRUM artifacts are used to help define the workload coming into the team and currently being worked upon the team. There are many more artifacts, for example, User stories, Release backlog, Burn-up chart etc. But we will concentrate on the core three:
The product backlog is a collection of user stories which present functionality which is required/wanted by the product team. Usually the product owner takes responsible for this list.
Sprint backlogs contain a collection of stories which could be included in the current sprint. Two important points to note about the relationship between the sprint backlog and the inclusion of items into the sprint. 1) The team decides what gets added to the sprint. The team therefore takes ownership and responsibility of the delivery of those items. 2) Before an item can be removed from the sprint backlog and added to the sprint, the team must ensure they have all the information needed within the backlog. Usually a team defines a checklist of items which must be present before the item can be added.
Product Backlog vs Sprint Backlog
The sprint backlog is a list of tasks identified by the Scrum team to be completed during the Scrum sprint. During the sprint planning meeting, the team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story as shown in the Figure below:
A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed. It is often used in agile software development methodologies such as Scrum. However, burn down charts can be applied to any project containing measurable progress over time. Outstanding work can be represented in terms of either time or story points.
Communication is key! SCRUM relies on all aspects of the team being and working transparently (scrum pillar #1). With this core ethos in mind, the methodology is structured around a number of key event for ensuring the two other pillars: Inspection and adaptation as shown in the Table below:
Note: There are five main meetings in Scrum during the execution of each sprint as shown in the Figure below:
All sprints begin with planning. The team needs to identify and commit to which items are going to be delivered as part of the sprint. The possible items are always taken from the Sprint Backlog as shown in the image below:
This is the time where the SCRUM master can shine. The product owner, identifies aspects they need from a business/customer point of view, the SCRUM team, identify which items they think they can deliver and the SCRUM master accommodates all and ensure the best of both worlds are met.
Daily Scrum Meeting
Once the team have identified the items they are committed to delivering as part of the sprint. The team will have a daily stand-up meeting. The core aim of this meeting is to ensure everyone within the team (and possible observers) full visibility of what the status of the tasks being done and progress:
What they have done
What they are going to day
What is stopping them
This daily update provides instance feedback to the team and provides. These meetings are meant to be short and snappy no longer than 3 minutes per person.
Observers are there to observe, the SCRUM master must where possible mitigate outside interruptions and distractions to the team.
Sprint Review Meeting
A Sprint Review/Demo meeting is held at the end of the Sprint to inspect the Increment. The Team demonstrates the Increment with focus on the Sprint Goal according to the Definition of Done. The Product Owner reviews and accepts the delivered Increment.
The sprint retrospective is usually the last thing done in a sprint. Many teams will do it immediately after the sprint review. The entire team, including both the Scrum Master and the product owner should participate. You can schedule a scrum retrospective for up to an hour, which is usually quite sufficient. The retrospective gives the team the opportunity to identify 3 key aspects:
What should starting doing?
What did not go well (and stop doing again)?
What went well (and should keep doing?)?
The aim of this approach is to continually improve the team efficiency.
Think of the backlog as the roadmap of the project. As the team collaborates to create a list of everything that needs to be built or done for project completion, this list can be modified and added to throughout the project to ensure that all of the necessary needs of the project are met.
In the Scrum Framework all activities needed for the implementation of entries from the Scrum Product Backlog are performed within Sprints (also called ‘Iterations’). Sprints are always short: normally about 2-4 weeks. Each Sprint follows a defined process as shown below:
As mentioned before, items in the product backlog are prioritize and selected to the sprint backlog. a sprint contains only a few large items, the impact of underestimating the work on even a single item will have a profound impact on the sprint. And since larger items tend to be harder to estimate and understand, the potential for a failed sprint increases further. Experienced Scrum Teams spend time and effort to break down complex and larger items (i.e user features or epics) into smaller user stories (or subsequently breaking down into tasks, or subtasks).
An epic captures a large body of work. It is essentially a “large user story” that can be broken down into a number of smaller stories. It may take several sprints to complete an epic. So when we take epic for development, it MUST be decomposed into smaller user stories.
Early in the project cycle, we come up with Epics. These are very high-level, almost marketing-centric, bullet-points of functionality.
We call large stories “epics” to communicate something about them. I like to think of this in relation to movies. If I tell you a particular movie was an “action-adventure movie” that tells you something about the movie. There’s probably some car chases, probably some shooting, and so on. Similarly, calling a story an “epic” can sometimes convey additional meaning.
A Stories is a brief statement of a product requirement or a business case. Typically, stories are expressed in plain language to help the reader understand what the software should accomplish. Product owners create stories. A scrum user then divides the stories into one or more scrum tasks.
A user story is typically functionality that will be visible to end users. A user story follows the format “I as WHO want to do WHAT, so that WHY. A user story delivers value to the customer/user. It’s a product requirement from the customer/user.
e.g. “As a customer, I want to be able to create an account so that I can see the purchases I made in the last year to help me budget for next year.”
A task, on the other hand, more a technical nature, Task is typically something like code this, design that, create test data for such-and-such, automate that, and so on. These tend to be things done by one person. A task is not written in the user story format. A task has more a technical nature.
e.g. “Evaluate Angular material design for user interface” or “Submit app to app store”.
About Visual Paradigm
Visual Paradigm help organizations stay competitive and responsive to change faster and better in today’s fast changing environment. Our award-winning products are trusted by over 320,000 users in companies ranging from small business, consultants, to blue chip organizations, universities and government units across the globe. It enables organizations to improve business and IT agility and foster innovation through popular open standards and process frameworks.Visual Paradigm, a killer Agile feature in 2018, introduced Scrum Process Canvas for automating the way a Scrum team to create, manage and deploy software application that empowers the team to continuously improve their performance at unprecedented speed and scale.
Manage the Entire Scrum Process in One Page
Automate the Scrum Framework in a fun and enjoyable dashboard with eye-catching updated status.
Manage Backlog, Multiple Sprints of different Scrum Roles with a single-page visually executable canvas
Allow instantly access, review and generate scrum artifacts and related documents to be archived in the Shared Cabinet
Automate the Scrum events and related activities with self-explanatory instructions, samples and required document templates.
Turn every software project into a successful one.