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.
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 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:
Following are the benefits that scrum provides to organizations, teams, products, and individuals.
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 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.
The main components of Scrum Framework are:
The diagram below shows the key elements of the SCRUM framework. The process has been applied by the agile software tool – Scrum Process Canvas.
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:
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:
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:
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:
| Event | Inspection | Adaptation |
|---|---|---|
| Sprint Planning | Product backlog (Commitments Retrospective) (Definition of Done) | Sprint goal Forecast Sprint backlog |
| Daily Scrum | Progress toward sprint goal | Sprint backlog Daily plan |
| Sprint Review | Product increment Product backlog (release) Market-business conditions | Product backlog |
| Sprint Retrospective | Team & collaboration Technology & engineering Definition of Done | Actionable improvements |
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.
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:
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.
Note That:
Observers are there to observe, the SCRUM master must where possible mitigate outside interruptions and distractions to the team.
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:
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. |
