The adoption of Agile has grown and evolved over the past decade, as organizations seek to adapt to changing industry needs and deliver products with higher quality and greater efficiency. Originally used in software development, Agile has now been adopted across all sectors and industries.
As reported in the 14th Annual State of Agile, a whopping 95% of respondents are known to practice Agile development methods, of which the majority (58%) prefer to use the Scrum framework and its variants. A promising way to advance your career using scrum in project management is with PMP certification courses.
What is Scrum Project Management?
Scrum is the most popular among all the Agile frameworks. It offers immense flexibility—in fact, Ken Schwaber, the co-founder of Scrum, preferred to call it a framework rather than a methodology, as it simply outlines the delivery structure and leaves it to the team to determine their own best practices.
In its simplest form, Scrum is a method of iterative and incremental product delivery that uses self-organizing and collaborative teams, who follow clearly laid out processes and follow prescribed events.
In Scrum project management, work is executed in short time-boxed cycles called sprints, and the team holds daily meetings to discuss planned tasks and any impediments that need to be cleared.
How does Scrum Project Management work?
Usually used in software development projects, Scrum project management works well with small teams and for projects that require rapid development and testing, even with emergent and volatile requirements.
Teams work in short sprints that are usually between 1 and 4 weeks in duration. This iterative cycle is repeated with a product incremental value being delivered at the end of each sprint. The cycle continues till the end of the project, when the entire product value has been delivered to the satisfaction of customers and stakeholders.
Since the tasks are reviewed at the start of each cycle, and there is continual seeking of feedback from stakeholders at the end of every cycle, Scrum adapts well to changing requirements.
This process is in sharp contrast to traditional ‘waterfall’ methods of software development, where the product scope is fixed upfront, and changes cannot be accommodated till the end of the project.
In waterfall projects there is the need for extensive documentation and analysis before development can start, which often delays schedules. What’s more, feedback is not sought till the end, which often results in low quality products that are packed with features that the customer is unhappy with.
The Scrum Framework
A Scrum project starts with a clearly defined product vision and an outline of the features and functionality it is expected to have. These features are prioritised and listed out in the Product Backlog, which is a dynamic document that is ordered with reallocation of tasks at the end of each iteration (called a sprint).
The sprint is a time-boxed event during which the team will complete a subset of the features and create a product increment that offers value. Sprints generally run for one to four weeks, a duration that is pre-set and is maintained through the project.
At the beginning of the sprint, the sprint planning event is held, and the team commits to developing items from the product backlog that are required to be done first. These items go into the sprint backlog, which is a subset of the product backlog and includes the features and functionality that can be developed during the sprint.
As the work progresses, the team meets daily, checking in with each other to discuss the progress of tasks. They tell each other what was done the previous day and plan the tasks for the day ahead and talk about anything that is holding them back from completing the tasks at hand.
At the end of each sprint, the team demonstrates the product increment to the stakeholders and obtains their feedback. In accordance with this feedback received, the product backlog is ‘groomed’ and the remaining tasks are rearranged according to the new priority. A retrospective meeting is also held where they discuss what went wrong during the sprint, and how they can improve upon this in the next sprint.
In this manner, Scrum processes follow the three pillars of Scrum: regular inspection, adaptation and transparency.
Scrum Roles
The Scrum Team is a small group of people; typically, between 3 to 9 in number, who work together without any hierarchy. The Team comprises three Roles: that of the Product Owner, Scrum Master, and Developers.
The Developers, also called the Dev Team, are the people who create the product increment during each sprint.
The Scrum Master, often referred to as the Servant Leader, is responsible for ensuring that Scrum practices as laid out in the Scrum Guide are followed. Scrum Masters serve the team (hence the name ‘servant leader’) and also the organization at large.
The Product Owner looks into the business side of things, and ensures that the product vision is followed. He or she strives to maximize the value of the product and manages the Product Backlog.
Top Cities where KnowledgeHut Conduct Project Management Certification Training Course Online
The Application of Scrum in Projects
Scrum is applied by following Scrum ceremonies, which are events held at specific instances during a sprint.
The main ceremonies are the following:
- The Sprint Planning Meeting is held at the beginning of the sprint and is when the entire team gets together to plan the upcoming sprint and finalise the user stories that will be completed during the sprint.
- The Daily Scrum is a short meeting, held daily at the same time, when each team member answers the following three questions: what tasks were completed yesterday, what are you working on today and is there anything blocking your progress?
- The Sprint Review is the event during which the team shows a demo of the work done to the stakeholders and elicits their feedback and the feedback from the rest of the team. This feedback is tracked by the Product Owner and is added as tasks to be undertaken in the upcoming sprints.
- The Sprint Retrospective is the last Scrum ceremony, which allows the team to reflect on the sprint that has just concluded and find ways of improving the work and processes for the next sprint.
Tracking Progress
The progress of the team’s work is tracked using three methods: the task board, the burndown chart and the Daily Scrum.
During the Daily Scrum, as already mentioned above, the team discusses what was done the previous day and what will be done during the rest of that day.
The task board typically has three columns: To Do, Doing, and Done. During the Daily Scrum, each team member will move items across the board (either using post it slips, or small chits that are pinned to the board) to indicate the progress of the tasks mentioned on each chit. It is a visual representation of what the team is working on at any given moment.
The burndown chart is a visual representation of the progress of work in the form of a chart, with the x-axis showing the number of days in the sprint, while the y-axis indicates the number of hours of work required to complete all the tasks for the sprint. The slope of the burndown chart should, ideally, come down to indicate that zero tasks are left when the time is completed.
Together, these three tools give a fairly accurate idea of the progress of the work. The team will be able to determine whether the tasks are likely to be completed on time, what the impediments to progress are, and how the tasks can be planned.
Looking to achieve mastery in project management? Our PRINCE2 Foundation certification classes online can help you enhance your skills with ease. With expert instructors and comprehensive materials, you'll gain the knowledge needed to excel in project management. Enroll today!
Grooming the Backlog
In between the sprints, it is important to carry out a backlog grooming or refinement session. This basically means that the scrum team meets and discusses the product backlog items and the work to be carried out in the next sprint. This helps in keeping the backlog up to date and getting it ready for the next sprint. Grooming helps to keep the product backlog de-cluttered, removes uncertainty and risk associated with the sprint, helps eliminate further meetings that may be associated with product backlog and leads to better sprint planning.
Release Planning
Release Planning, usually done once in a quarter, is done for multiple sprints together. This is a longer-term plan that is undertaken to get a perspective on when the product release is likely to happen and evaluates value and quality constraints against the available time, resources and budget.
The PO presents the list of features that must be completed during the upcoming quarter, and the team provides gross, rough estimates to check whether this will be feasible. The result of the meeting is internal and does not have to be showcased to the customers.
Case study on Scrum in project management
While Scrum is most commonly used in software development projects, there are many examples of how Scrum has proved to be of great advantage in non-Scrum projects as well.
A Scrum.org case study outlines the journey of a major US Airline with over 4000 employees that leveraged the Nexus+ framework to scale Scrum across more than 10 globally distributed teams. The result was clean, streamlined processes, with a stunningly quick turnaround and improved ROI.
This company had earlier used waterfall methods to create and manage their software products, and it would typically take them months or years to deliver a product to market. In multiple cases, by the time the product was ready to ship it was no longer usable due to the huge lapse of time in the interim.
Lola Tech was one of their software vendors, and their Head of Delivery decided to adopt agile across their entire product development suite for this company. Most of them had already worked with Scrum, and Nexus was their obvious choice.
When they started the adoption, they faced challenges in:
- The capability of building cross-functional teams, so that outside dependencies could be removed
- The culture shift: changing from a Project Mindset to a Product Mindset
- Being able to apply the Scrum framework effectively in its entirety, not just in parts
- Building psychological safety across teams
- Strictly following the Scrum Values in mind and spirit
Getting the teams trained was the first and most obvious step. PSTs trained the team members as well as vendors to achieve certifications that included PSM, PSD, PSPO and SPS, getting them aligned with the values and principles embodied in Scrum.
Once the team had their fundamental knowledge in place, they created an Agility Transformation Backlog and roadmap. Each of the challenges was broken down and solutions found—ranging from organizing team events to foster connections between remote teams, to properly understanding how to apply the framework effectively.
There were 5 Nexuses with each Nexus consisting of 5 to 9 Scrum Teams. Together, they worked on a product family made up of an operations platform for handling products sold, and two e-commerce platforms - a custom one, and another one for selling additional goods and/or services. These teams were brought in line to work with shared goals and a common vision and mission.
After the first product releases, the results were quite astounding. They were able to achieve:
- Decreased Time-to-Market - From delivering yearly or twice a year in a waterfall fashion to delivering better software products, every quarter
- Increased Profits – Achieving a 100% ROI in just 2 weeks after going live
- Faster delivery - From getting the first releasable increment ‘Done’ in 2 months to having a releasable increment after a two-week Sprint
- Greater collaboration - From the Dev team having zero interaction with the PO, to all the Developers having daily interactions which increased transparency and accountability
- Slashed Costs - By automating deployments, features and releases they were able to cut costs dramatically.
There are many more such case studies at this link.
Understanding the Project Manager Role in Scrum – The Scrum Master vs the Project Manager
Both the Scrum Master and Project Manager are roles that maximize value for projects. While there are similarities between the two roles, the responsibilities of each are quite different.
A Scrum Master is the servant leader on a Scrum team, who ensures that the team adheres to Scrum values, and acts as a mentor, guide, leader and facilitator all rolled into one. The Scrum Master works with only the Scrum framework and does not adopt other methodologies.
The Project Manager, on the other hand, is a leader who manages one or several teams to plan, execute and deliver projects, maintaining complete control and responsibility over the project in its entirety. A Project Manager is free to choose traditional or Agile methods or choose a hybrid model, based on the approach that is considered most suitable for the project.
The Scrum framework helps organizations to address challenging adaptive problems, delivering products of the highest value. Scrum values, principles, and practices have been proven to empower businesses to adapt to volatile conditions, developing products that delight customers in a quicker time, with optimal use of resources.
The Scrum Framework continues to be the preferred choice of agile practitioners. As its popularity continues to soar, with no signs of slowing down, it’s indeed time to go down the Scrum path!
.png&w=3840&q=75)
.png&w=3840&q=75)
.png&w=3840&q=75)
.png&w=3840&q=75)
