Scrum Project Management: What you need to know

How Work Has Changed

Work is an ever-evolving aspect of our daily lives. It wasn’t too long ago that work was understood to be much closer to craftsmanship and manual labor during earlier pre-industrial periods. It was in the 1950s that the most recognizable version of project management came to fruition, just after World War II and in the midst of the economic boom that a post-war Western civilization was experiencing. It was here that we were introduced to concepts of project organization through works by Henri Fayol and Henry Gantt (of the Gantt Chart fame).

Naturally, evolving technologies continued to move forward and introduced more complex methodologies for tracking and measuring progress across several projects. Richa Dhall, sharing with LinkedIn, notes that “All this changed the way we worked, performed tasks share data and ROI (Return on Investment) converted into ROTI (Return on Time Invested). Every task was being done faster and the projects were expected to finish in much less time than before.”

With all this, technologies kept developing further and software companies were the first to notice the need to introduce better systems in place to address fast-moving market competitors. However, programming remained a long and tedious process, and key business leaders were keen to look for ways to better improve product turnaround times in response to both market and consumer developments and feedback.

Quick History of Scrum Management

During the 1990s, Jeff Sutherland and Ken Schwaber introduced a published version of the first iteration of what is now known as “Scrum Project Management”. It’s important to note here that what they had formally developed wasn’t entirely novel by any means, but is better understood as a coalition of different agile methodology principles that were being used by companies in the industry.

By this time, there were a few ways a company could choose to better be agile in their product stages, utilizing methodologies like Waterfall cadences in an effort to react quickly to needed changes in their development processes. Schwaber, in a published whitepaper on his website, stated that while systems like Waterfall can be efficient in product development, it also relies on a well-understood and standard expected process. Real-life scenarios, Schwaber argues, are much more volatile in nature and require much more consistent feedback regarding needed changes and iterations.

In 1994, a key article was written for the Harvard Business Review outlining a “new new” product development method. This article, written by Hirotaka Takeuchi and Ikujiro Nonaka, outlines a theory in project management that can allow managers and teams to avoid the “relay approach” and instead work within specialized teams to push a product forward in a “scrum”. Scrum itself was a term that the duo took from how rugby teams would work together as a unit to bring the ball to the goal.

With this article and the accompanying admittedly fitting term, Schwaber and Sutherland laid out a more comprehensive version of this methodology and presented it at the OOPSLA’95 (Object-Oriented Programming, Systems, Languages and Applications) conference.

How Scrum Works

While history shows us the context of why a system like this was necessary to better accommodate the growing movement towards newer agile methodologies, the exact processes within it can be daunting for the first-time reader to fully understand. Essentially, a scrum is a method of providing fast incremental development schedules to get viable product iterations out to the market within a short time period (usually 1-4 weeks).

These scrum sessions refer to short meetings where team members, product managers, and scrum masters connect to review the current status of the product at hand. This can come in the form of discussing major successes, immediate concerns, and even future challenges that they anticipate coming from the market. The ultimate goal of these meetings is to expedite the delivery of a high-quality product that’s better informed by both internal and external insights.

Again, Scrum itself isn’t the only way to put into practice the agile perspective in your work nor is it fully confined within the software development space. Scrum’s main purpose is to provide an overall framework for teams to follow that is grounded in action, review, and adaptation in a short but efficient process. In this way, Scrum is flexible enough to be incorporated into different contexts while allowing some modicum of guidance for teams navigating unclear development processes.

Main Scrum Processes

The Scrum framework, as Schwaber and the Project Management Institute (PMI) outlines it, is less of an exact step-by-step methodology but rather a structure in which teams can populate their own processes in a more organized manner. The main components of a scrum that a project manager should be aware of are Product Backlogs, Sprints, and Product Increments, which in themselves contain subcomponents that managers will need to take into account for a successful scrum.

The Product Backlogs

As a precursor to the entire product, a clear goal for the business is defined as an overarching objective for the team at large. After this, product backlogs are defined, which are essentially a set of product features that are informed either by market need, competitor development, customer feedback, or other aspects that can influence feature implementation. It’s here that designated “Product Owners” are responsible for managing communication of these requested features between the “Scrum Master” and the “Scrum Team”.

The Sprints

A time frame or “time box” is then set, which in the scrum framework is known as the individual iteration or “sprint”. With this sprint, a duration is established between all scrum members, in which they are to deliver upon the features selected as part of the product backlog. The time needed for each sprint varies but is usually set at a standard of 1-4 weeks.

This is an integral baseline to work with as it essentially establishes the cadence in which the scrum team works to develop the product according to the agreed-upon features, which is derived from the product backlog and is defined as the “sprint backlog” for the specific sprint in question.

During the sprint itself, the scrum team is allowed full focus and allocated resources to finish the sprint within the allotted time. It’s important to note here that the scrum will require hands-on management from the Scrum Master as issues will likely pop-up during these developmental periods. Depending on the time sensitivity of the product, the allotted time might be adjusted to better accommodate any critical concerns.

The sprint work itself is not to be changed during this period, meaning that no additional features should be injected during the sprint itself. Further product development requests can be added to subsequent product backlogs that, in turn, will be developed in subsequent sprint backlogs. Within these sprint periods, the scrum teams, along with the scrum master and the product owner, if needed, will reconnect over short meetings (standard lengths ranging from 15 to 30 minutes) to align on finished tasks, what they plan to complete by day’s end, as well as any major hurdles in the way of specific work to be done. These short meetings are a fantastic resource for cross-functional work especially as the team gets closer to finishing their sprints.

Product Increments Review

It’s after these individual sprint sessions that the short but albeit key aspect of scrum comes into play through incremental product reviews. Some scrum resources might refer to this method as backlog refinement, grooming, or other similar terms.

The essential aspect of this scrum component is to review the state of the product at its most recent iteration after the sprint, reassess whether the current product backlog is still relevant and if any adjustments toward development processes are needed. This will include getting feedback from internal and external stakeholders to see where and how they can improve.

It’s here that scrum leans into the action, review, and adaptation principles that we’ve mentioned earlier. Without this last review and adaptation step, the product is likely missing out on key features that might be integral to product success in the market. With today’s landscape rapidly shifting in terms of what’s likely to be developed in the coming few months, it’s of absolute importance to consistently revisit where the product is and adapt accordingly within the scrum framework.

Key Scrum Roles

Despite the relatively robust walkthrough we just discussed regarding the overall process that scrum goes through, the number of key roles within the framework is relatively simple by comparison. Scrum needs just three main roles to be properly defined in order to be fully functional for project management purposes. Based on Certified Scrum Trainier Mike Crohn for ScrumAlliance.org, these roles are defined as the Product Owner, Scrum Master, and Scrum Teams.

The Product Owner

Essentially the customer-facing and business-focused side of the scrum project, the product owner manages and liaisons between the scrum master, the scrum team, and any other internal or external stakeholder that will have influence over the project. The product owner can also be understood as a key voice for the eventual shape and end version of the product in accordance with the project’s main business vision.

With many changes likely occurring between each product backlog and subsequent sprint, it’s the product owner that needs to be fully accountable for the adherence to the key elements that are needed for the success of the product in the market. They’ll also need to be adept in communicating this vision both to the scrum master and the scrum team as these latter two will be in charge of the managing and actual development of the product properly.

Skilled Product Owners know how to leverage product backlogs as a way to better align everyone with priority items for the project development as they will likely be the one who fully understands what users of the product are looking for. Industry knowledge and foresight are key to this as they need to be able to adapt to any seen (and unseen) changes in the market.

The Scrum Master

If the Product Owner is in charge of the business and end-user aspect of the product, then the Scrum Master is in charge of managing the development process side of the project. Their primary role is to ensure each scrum team member understands the coverage of the scrum as well as their individual roles within it.

Acting as an overall facilitator, guide, and coach throughout the process, the Scrum Master is expected to be able to understand the operational flow of what each sprint will entail as they need to carefully navigate concerns that the Scrum Team might have. Given tight timelines within each sprint (1-4 weeks), a steady hand by the Scrum Master is an absolute necessity in keeping everyone on track.

Taking on this supervisory role, it’s essential for the Scrum Master also to be aware of the limits of their respective Scrum Teams to avoid any over-capacity issues with their tasks. The Scrum Master can also provide lateral-thinking guidance to better assist Scrum Team members out of development ruts.

The Scrum Team

Last but definitely not least, the Scrum team is in charge of the meat of the scrum project. While the Product Owner and the Scrum Master manage and delegate tasks, the Scrum Team carries out the development and implementation in the sprints proper.

These Scrum Teams are by-and-large multi-disciplinary, often consisting of individuals with different focuses on the project, such as business analysts, product testers, product developers, marketing managers, and even financial managers.

It’s this team that works together in sprints in an effort to meet sprint backlogs, leveraging each other’s expertise during their daily scrum meetings as well as providing assistance wherever they can within the current sprint.

The eventual outcome you want from a fully functional Scrum Team is one that practices a strong sense of autonomy and ownership with their work. Self-organization and confidence in their capabilities during crunch sprint phases are necessary to produce the best results for the product’s iteration.

With these three roles defined, you can better create delineation between responsibilities and cut down on any inefficiency generated by work overlaps and misunderstandings. Clarity and organization are key to Scrum Project Management and remain a key principle in how agile methodologies work as a whole.