Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
What is Scrum?
Scrum isn’t a fully-featured project management methodology. Rather, it describes an approach to Agile management with a focus on project teams, short “sprints” and daily stand-up meetings.
While it borrows the principles and processes from Agile, Scrum has its own specific methods and tactics for dealing with project management.
“Agile is the philosophy and Scrum the methodology. While Scrum is agile, agile isn’t scrum.”
The Scrum approach places the project team in front and center of the project. Often, there is no project manager. Instead, the team is expected to be self-organizing and self-managing. This makes it ideal for highly focused and skilled teams, but not so much for others.
Advantages of Scrum
Scrum “sprints”: The Scrum approach is heavily focused on 30-day “sprints”. This is where the project team breaks down a wishlist of end-goals into small chunks, then works on them in 30-day sessions with daily stand-up meetings. This makes it easy to manage large and complex projects.
Fast paced: The “sprint” approach with its 30-day limit and daily stand-up meetings promotes rapid iteration and development.
Team-focused: Since the project team is expected to manage itself, Scrum teams have clear visibility into the project. It also means that project leaders can set their own priorities as per their own knowledge of their capabilities.
Besides these, it has all the benefits of Agile – rapid iteration and regular stakeholder feedback.
Disadvantages of Scrum
Scope creep: Since there is no fixed end-date, nor a project manager for scheduling and budgeting, Scrum can easily lead to scope creep.
Higher risk: Since the project team is self-managing, there is a higher risk of failure unless the team is highly disciplined and motivated. If the team doesn’t have enough experience, Scrum has a very high chance of failure.
Lack of flexibility: The project-team focus means that any resource leaving the team in-between will hugely impact the net results. This approach is also not flexible enough for large teams.
Scrum is best for
The Scrum approach is best for highly experienced, disciplined and motivated project teams who can set their own priorities and understand project requirements clearly. It has all the flaws of Agile along with all its benefits. It works for large projects but fails if the project team itself is very large.
Below diagram depicts the core values of the Scrum framework.
This is not about the expectation that all scope will be delivered, no matter
Commitment is about dedication and applies to actions, the effort, not the final result
Maximum possible effort for achieving the goal and will be transparent
Commitment towards –
Focus on what is most important now
Future is highly uncertain, focus on YAGNI – “You aren’t gonna need it”
Focus on the simplest thing
Be transparent, inspect in order to make sensible adaptation
Open about our work, progress, problems, and learnings
Open for people and working with people
Acknowledging people to be people, and not resources, robots or replaceable machinery
Open to collaborate with stakeholders and wider environment
Open in sharing feedback and learn from one another
Open for change
Respect for people, their experience and their personal background
Respect different opinions, we might learn from it
Respect for our sponsor by not building features that nobody will use
Respect for users by fixing their problems and quality product
Respect for wider environment by not behaving as an isolated island in the world
Respect each other’s skills and expertise
Courage to not build features that nobody wants
Courage in admitting requirements will never be perfect
Courage in admitting that no plan can capture reality and complexity
Courage to not deliver undone features
Courage to share risks and benefits
Courage in sharing information that might help team and the organization
Courage to change direction
Roles, Artifacts, and Events in the Scrum Framework
Below diagram depicts various roles and their correlation in the Scrum framework.
Various roles that comprise of scrum framework are:
A Scrum Master is a team leader and facilitator who helps the team members to follow agile practices so that they can meet their commitments. The Scrum Master is responsible for ensuring Scrum is understood and enacted.
A Scrum Master serves the Scrum Team
Lead by example. Be the first one to be vulnerable. Be a living demonstration of team assets and scrum values. Admit your missteps.
Create an environment of safety. Encourage debate, support it and keep it productive. Use coaching techniques like open questions.
Facilitate Consensus. Try to have key decisions made clear at the end of team discussions, making responsibility and deadlines clear.
Learn to read the room. Be connected without being present.
Show patience. Be okay with silence. Let the team take action.
Restrain from solving. Reveal, not resolve. Be careful not to steer the team towards premature resolution of conflict to protect people. Help team members develop conflict resolution skills.
Be comfortable with failure. Team decisions may not lead to the anticipated outcome. This is part of learning and growth.
Care for people. Listen to them without judgement. Assume positive intent. Meet them where they are and help them find the next step.
Show low tolerance for organizational impediments.
Below diagram depicts the misunderstood stances of a scrum master
Stances of a scrum master
Stances of a scrum master are:
Scrum Master as a Servant Leader
Setting up Scrum as a servant process, not a commanding process
Guiding the Development Team towards self-organization
Leading the team through healthy conflict and debate
Shielding the team from disturbance and external threats
Helping the team make visible, remove and prevent impediment
Creating transparency by radiating information via Scrum events and artifacts
Scrum Master as a Coach
Coaching the Individual in –
Focusing on mindset and behavior
Using Scrum well
Taking next step in his/her Agile journey
Coaching the Team in –
Creating a learning culture
Changing mindset for continuous improvement
Problem solving and conflict resolution
Coaching the organization in –
Collaborating with the Scrum team
Doing product management with a focus on business value
Delivering high quality and valuable products
Scrum Master as a Facilitator
Facilitate the Scrum process and the continuous improvement of the process
Facilitate the integration of Scrum team into the wider organization
Facilitates the Scrum events to be purposeful and effective
Daily Scrum – an atmosphere where healthy peer pressure occurs on delivering quality, commitment and addressing impediments
Sprint Planning – collaboration between the Development Team and the Product Owner, keeping a strong focus on delivering value
Sprint Review – Scrum team, sponsors and stakeholders collaborate to work as One team with the same purpose
Sprint Retrospective – a safe atmosphere in which “elephant in the room” is addressed
Scrum Master as a Teacher
Teach Agile during the team start-up
Teach the Scrum team about Empiricism
Teach about Scrum to Scrum team and other stakeholders
Teach the difference between Scrum the Best practices
Teach the team about the self-organization
Team the team about removing impediments
Teach the team about the importance of the product vision
Team the team about visualizing progress
Teach the Product Owner about Backlog Management
Teach the team to have fun
Scrum Master as a Mentor
Shu – Follow the Rules
Scrum Master acts as a teacher
Shares knowledge and skills
Provide instructions on “How to do”
Ha – Break the Rules
Offers new perspectives and possibilities
Ri – Be the Rule
Act as a counsellor
Give advice whenever asked for it
Scrum Master as a Manager
Manages the process
Manages the boundaries of self-organization
Manages the team’s health
Manages the culture
Scrum Master as a Impediment Remover
Respect the self-organizing capability of the development team
Creating environment where Development Team feel safe to raise impediments
Understand the meaning of “Impediment”
Don’t wait until the Daily Scrum
Improve transparency by using the Impediment board
Be bold and creative in removing impediments
Scrum Master as a Change Agent
Creating an environment that allows the spirit of Scrum to thrive
Leading and coaching the organization in its Scrum adoption
Helping employees and stakeholders understand and enact Scrum development
Causing change that increases the productivity of Scrum Team
Working with other Scrum Masters to increase the effectiveness of Scrum in the organization
Planning Scrum implementation within the organization
Scrum Master Service to the Product Owner
Finding techniques for effective Product Backlog management.
Helping the Scrum Team understand the need for clear and concise Product Backlog items.
Understanding product planning in an empirical environment.
Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.
Understanding and practicing agility.
Facilitating Scrum events as requested or needed.
Scrum Master 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.
Facilitating Scrum events as requested or needed.
Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
Scrum Master Service to the Organization
Leading and coaching the organization in its Scrum adoption.
Planning Scrum implementations within the organization.
Helping employees and stakeholders understand and enact Scrum and empirical product development.
Causing change that increases the productivity of the Scrum Team.
Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
It is the team which works for SDLC of the application. This team includes developers, testers, technical lead, product owner and scrum master. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.
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 the skills as a team necessary to create a product Increment;
Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing or business analysis; there are no exceptions to this rule.
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
A Product Owner drives the product from business perspective and is the one who decides and defines requirements, prioritize their values and release dates. Product owner is also involved in iteration planning and release planning meetings.
Clearly expressing Product Backlog items;
Ordering the items in the Product Backlog to best achieve goals and missions;
Optimizing the value of the work the Development Team performs;
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next;
Sprint backlog consists of the selected product backlog items and a plan to deliver them.
Selected Product Backlog items are often decomposed.
Work for the Sprint emerges.
Development team members sign up for work, they aren’t assigned.
Development team members may modify the Sprint Backlog anytime, as they see fit.
The product backlog is a list of all the product features generally defined by “user stories”. User stories define everything potential users want to do on the site. There are many tools to keep track of your project backlog, both analogue and digital options.
After all user stories are created, they are ranked based on the priority and grouping on the stories. Grouping is done based on the inter-dependencies of the stories
Agile projects are broken down into small, consistent time intervals. These intervals are referred to as sprints.
Sprints are time-boxed iterations that serve iterative-incremental development.
All development is done within a sprint
A Sprint contains the time-boxed scrum events
A Sprint is one month or less, and it is best to have a consistent duration
Sprint length is determined by acceptable planning horizon
Scrum known no phases, only Sprints
No testing, hardening, release, analysis Sprints
The entire point of Scrum is to create a Done increment
A sprint has a time duration of 1 – 3 weeks depending on the extent of the overall project. Before each sprint, there is a sprint planning meeting. This meeting determines what the goals are for that sprint. Based on the team velocity, a set of features are pulled from the top of the backlog. During the sprint, no features are added, and the sprint goals don’t change
This is the first meeting of every sprint and the amount of work which can be achieved in the sprint is decided in this meeting depending on the team velocity. User stories are assigned to the dedicated team as per the requirement and analysis.
Every morning of the sprint the project team gets together for a short (under 15 minute) meeting. This meeting takes place at the same time every day and includes everyone on the project.
15-minute time-box daily event.
Consistent place and time.
Development team inspects their progress toward the Sprint goal
Development team creates a plan for the next 24 hours.
Not a problem-solving meeting.
Not a status meeting.
Each person on the team is tasked to answer 3 simple questions:
What did you do yesterday?
What you are going to do today?
Any blockers or dependencies in your way?
Sprint Review/ Retrospective Meeting
At the end of every sprint, A Sprint Retrospective meeting takes place with a functional demo of the user stories that has been completed during the sprint. The sprint review meeting brings together the project team and other project stakeholders like the client to present the work that was completed.
Scrum Team inspects how the last sprint went
People, relationships, process, tools
Definition of “Done”
Scrum team selects actionable improvements for implementation in next Sprint.