Executive Summary

Two of the most important leadership roles within a Software Development Team are the roles of the Scrum Master and Product Owner. Together, they often serve as the primary point of contact between the Client Business Unit (whether internal or external) and the rest of the Software Development Team. In this blog article we will cover the following:

• Role of the Scrum Master
• Role of the Product Owner
• Can they be Combined?

‍

Role of the Scrum Master (a.k.a. Agile Project Manager)

The Term Scrum Master comes from the most common Agile Software Development Lifecycle methodology, that first began in the late 1990’s; known as Agile SCRUM. It is a Rugby term, where a Scrum (or group) of players are trying to work together to get the ball over the goal line and score.

Likewise, the Scrum Master is the team leader who is facilitating moving the ball further down the field. When to pitch it to another player, when to run with it, or when to bunch up in a scrum and force the way forward. Unlike in a Traditional Project Management role, the Scrum Master is a member of the team and only “First among Equals.”

Their primary responsibilities include:

• Manage the relationship with the Client Business Units‍

• ‍Facilitate and coordinate all Team meetings:‍
• Daily Stand-ups
• Sprint Planning
• Demos & Reviews with the Client Business Units‍

• Administrate & Manage Agile Projects:
• Creating the Project(s)
• Creating the Phases or Release Schedules
• Setting up & Closing Sprints (2-week development cycles)
• Changing Workflows & Kanban Boards

• ‍Measure & Monitor the Teams’ Productivity:
• Burn Down Charts - are we on Track, Ahead of Schedule, or Behind Schedule
• Burn Up Charts - are we managing our Scope correctly and only Pulling In what we can actually accomplish in a Given Sprint:‍
• Trying to do too much, often leads to individuals being overwhelmed and thus lower productivity‍
• Velocity Charts - how many “Software Points” can a Team manufacture or produce in a given Sprint?  Ideally, just like in a manufacturing line, you want to attain a regular and predictable flow of production, and avoid wide swings.
• Defects Detected and QA Test Coverage

• Facilitate Retrospectives, After Action Reviews, and Lessons Learned.
• Handle any and all required Managerial Reports.
• And most importantly, help the Team remove any and all Impediments or Issues which they encounter.
  

It is important to note that the Scrum Master does not Command and Control the team, rather facilitate their success.

‍

Role of the Product Owner (a.k.a. Business Analyst)

The term Product Owner came about because originally Agile Techniques were first used within Software Companies, where the individual doing the business and product analysis was typically a Software Product Manager. Hence the term “Product Owner”, since they owned the long term Product Roadmap and vision for the product that the team was working on.

This term stuck, although some organizations will call them Business Analyst or have alternative titles. The role is ultimately very similar. The biggest difference between an Agile Product Owner and a more Traditional Business Analyst, is in the way of thinking and the approach that is taken.

There is also in most cases a major difference in how we estimate the work required.‍

- Category: Business Requirements

Product Owner:

Epic Stories broken down into smaller User Stories.

Traditional BA Approach:

Huge requirements specification up front, but who reads 150 pages and understands it?

- Category: Estimates Based On

Product Owner:

Complexity of the work “Software Points” function point Analysis.

Traditional BA Approach:

Number of hours.

- Category: Change Management

Product Owner:

Changing requirements are expected, only major additional scope requires a change order.

Traditional BA Approach:

Change is not expected, everything becomes a change order.

- Category: Product Roadmap

• Typically planned in phases or releases (approximately every 3+ months).
  
• Current phase has the most detail.
  
• Future phases are kept more at the epic Level.

Traditional BA Approach:

• Detailed 12-month Product roadmap.
  
• But change happens so frequently, that anything beyond 3 months is a guess, and can create false assumptions or false expectations.
  

‍

What are Software Points and Why Use Them?

A Software Point is a relative measure of the Complexity for Designing, Developing, and QA Testing a particular Feature or Function within an Application, whether this is a new Application, an Enhancement, or Modification (Refactoring).

Most organizations use a modified form of a Fibonacci Scale, to identify the Complexity of Building the item, given all of the work required to Build it, without consideration for Who is actually doing the work. The goal is not to measure the “Time” required by an individual, but rather the Complexity of Building the Item and making it Production ready.

The reason for this is that even during the Course of a given Sprint (2-week Production Cycle), you may need to shift resources around on the team, team members may get sick, and unexpected things may happen. In addition, by measuring every item in terms of Software Points, allows us to determine over time the Team’s Velocity in terms of how many Points they can do on average each Sprint. And you can start to see patterns occur, if the Team takes on too much work or areas that need to be improved upon.

Normally, the Product Owner or the Scrum Master, will take a first crack at Pointing the Items in the Backlog, which gives the Team an initial analysis of each item's complexity. Then when it is assigned during Sprint Planning, the Team Members working on that item (Dev and QA), should adjust the Software Points, as they see fit. Sometimes, this won’t be known until they start working on the Item / Story, so expect some adjustments in the Software Points assigned to the Sprint (up and down).

Items that the Team should “Point”

• User Stories (or System Story)‍
• “As a User, I need to do XYZ, in order to get this business value.”
• “As ___ System, I need to do ABC, in order to get this business value.”

• Research Stories - when you need to analyze and consider the best approach‍
• Buy vs. Build
• Different Technology Options
• Feasibility of an Approach - can it be done? Etc.
• The output is typically an Analysis and Recommendation Document, High Level Design, & Architectural Diagrams

• Enhancement / Refactoring User Stories - where an existing portion of the application needs to be enhanced or replaced (refactored)
• Bugs / Defects (Post Development) - most organizations only track Bugs / Defects that make it past Code Review and into the QA Testing Process, User Acceptance Testing, or Production.  However, in all cases, these Bugs should be assigned Points as well, depending upon the Complexity to Fix and Re-Test.

Guidelines for Pointing Items

When Pointing a particular Item, there are several things to consider, in terms of Complexity:

• Analysis Work
• Detailed Design Work
• Coding Work
• QA Testing Work
  

This is critical, because an Item may be very easy to Code, but extremely difficult and complex to accurately QA Test. And vice-a-versa.

‍

SOFTWARE POINTS: 0

Mode of Transportation: Your Feet

Examples:

• A very simple task that needs to be tracked, but is already done - like pushing Code to Production.

‍

SOFTWARE POINTS: 1

Mode of Transportation: Skateboard

Examples:

• Adding simple Fields to a Form
• Adding Columns and sort order to an existing Report or List
• Creating a simple Dialog Box
• Most Bugs / Defect Fixes
• Changing UI colors, font sizes, font styles, etc.

‍

SOFTWARE POINTS: 2

Mode of Transportation: Bicycle

Examples:

• Adding Fields to a Form with validation rules
• Implementing basic Filters on a Report / List
• More complex Bugs / Defects
• Creating a Basic Form with only a few fields
• A very basic R&D Analysis Story

‍

SOFTWARE POINTS: 3

Mode of Transportation: Scooter

Examples:

• A complex Body Section on a Form with a table
• Creating an Action Bar used by multiple Screens / Lists
• Creating a moderately complex Report / List
• Implementing a Basic Db Table

‍

SOFTWARE POINTS: 5

Mode of Transportation: Motorcycle

Examples:

• Creating a Micro-Services End-Point
• Creating a Read Micro-Service
• Creating a Create / Edit Micro-Service
• Implementing a more Complex Db Table
• Creating a complex Report / List
• A moderately complex R&D Analysis Story

‍

SOFTWARE POINTS: 8

Mode of Transportation: Car

Examples:

• Moderately complex Business Rules or Processes
• Complex Micro-Services
• Very complex Report / List

‍

SOFTWARE POINTS: 13

Mode of Transportation: Formula 1 Race Car

Examples:

• A complex Business Rule or Process
• A complex R&D Analysis Story, with lots of documentation, design diagrams, architecture, etc. that must be produced

‍

SOFTWARE POINTS: 20

Mode of Transportation: Biplane

Examples:

• EPIC Story - at this size, this should be an EPIC and broken into multiple smaller Stories
  

‍

Supporting Each Other & the Team

While this is not true for every individual, in many cases the Competencies, Knowledge, Skills and Abilities are very similar between a Scrum Master and a Product Owner. When a Team contains both Roles, this gives you an inherent ability to have them cover for each other, or assist when there are more Tasks required for one role or the other. This gives the Team a lot of flexibility and makes it easier to maintain the Velocity (Productivity) and Efficiency of the Team.

Likewise, the two individuals may decide to divide up some tasks, based on their own background and experience, leveraging the person who knows a given Tool or Function the best. This is very common and should be encouraged where it makes sense.

To a lesser degree, both the Product Owner and the Scrum Master, can also pitch in and help out the QA Engineers on the team in performing testing.  In most cases, this won’t involve performing Automated QA Testing, but rather playing the role of an actual Business User (or Consumer) using the Application and trying to see what works and what doesn’t, and documenting their actions and results. This type of “Gorilla” Testing, can be very valuable, as they may end up testing something that no one thought of, but a real User might actually perform.

‍

What about Combining the Roles?

In a few cases, it is possible to combine these Roles into one person. Before you do this, here are some considerations to take into account:

• This works best for:
• Small teams of roughly between 4 to 6, OR
• The Majority of Requirements are known (such as a conversion or migration project), so there is not a lot of Analysis required, OR
• Other Team Members have both the Skill Set and Experience to step in and help out in either of these Roles as required. Often this may be the QA Engineer or Tech Lead on the Team.

• Executive Management needs to constantly monitor the Team to make sure that the person filling both Roles (SM & PO) doesn’t get overwhelmed or worse burned out from the pressure and stress.

• Combining these Roles into a single person rarely works:‍
• If the Project involves a brand-new Application or Concept, as this can take a lot of analysis work.  
• And if the PO falls behind in Producing Stories / Items for the Team, then they have become a Bottleneck and will slow the entire Team down.  
• You do not want to have the Developers sitting on their hands doing nothing, waiting for the Combo SM/PO to create Stories for them to work on.  
• If this starts to happen, then you know you need to Split the Role into Two ASAP.

• If you are going to Combine the Role, make sure the Person can actually do both jobs successfully. And if they have never performed that function before, make sure to give them the support they need.
  

‍

Conclusion

We have covered the Agile Roles of both the Scrum Master and Product Owner, as well as how they can Support one another and the Team, and the few occasions when it makes sense to Combine the Roles.

We hope that you have enjoyed this Blog Article.

Thank you, David Annis.