Skip to content

Agile Scrum Note 03

Roles in Scrum

Stakeholders

  • Anybody whose interest is positively or negatively affected by the project OR who can exert an influence on the project
  • Examples:
    • Team (Product Owner, Scrum Master, Developers)
    • Management
    • Customer
    • End users
    • Vendor/Contractors or external contributors
    • People whose roles are “displaced” or “affected”
  • Chicken (involved) v.s. Pig (committed) roles
    • Responsible
    • Accountable
    • Concerned or Consulted
    • Informed
  • Stakeholder management
    • Identifying stakeholders
    • Assessing their knowledge and skills
    • Analyze the project to ensure their needs are met
    • Get and keep them involved by assigning them work, using them as experts, reporting to them, involving them in changes & lessons learnt
    • Getting their sign-off and formal acceptance during closure
    • Establishing a “rapport” with them!

Product Owner

  • One of most critical roles in Scrum
  • Part of the Scrum Team which includes Scrum Master and developers
  • Provides direction to the team
  • Role
    • Manage the Project’s RoI and risk
      • Build business cases for projects and features
      • Be cognizant of the risks
    • Take inputs from all stakeholders about what the team should do
      • And translate that into a backlog
    • Assign priority to items in the backlog
    • Determine the release plan with help of the team
    • Communicate the plan and roadmap with the external stakeholders
    • Participate in the important Scrum meetings
      • Release and Sprint Planning
      • Sprint Review
    • Be available for the team for
      • Clarifying requirements
      • Answering questions
      • Providing feedback
  • Prioritization
    • Prioritizing requirements is an important role played by the Product Owner
    • Prioritization is essential to ensure that the available time and budget is spent on delivering whatever is MOST valuable to the customer
    • Possible justification for features:
      • New revenue
      • Incremental revenue
      • Operational efficiency
      • Catch-up with competitor
  • Cost-Benefit Analysis
    • Define the investment timeframe
    • Forecast investment needed and recurring costs
    • Forecast financial benefits
    • Use time value of money and a combination of measures to decide
      • Pay-back period
      • Net-present-value (NPV)
      • Internal Rate of Return (IRR)
  • Prioritization based on Value and Risk
    • HIGH value, LOW risk -> DO FIRST
    • HIGH value, HIGH risk -> DO NEXT
    • LOW value, HIGH risk -> DO LAST
    • LOW value, LOW risk -> DON'T DO
  • Prioritizing requirements - MoSCoW
    • Must
    • Should
    • Could
    • Won't
  • Prioritizing requirements – Kano model
    • Threshold / Must have’s: those that must be present in the product for it to be successful
    • Linear Feature: those features where customer satisfaction is correlated linearly with the quantity of the feature
    • Exciters and Delighters: those features that provide great satisfaction, often adding a price premium to a product. But the lack of exciter or delighter will not decrease customer satisfaction below neutral
  • Prioritizing requirements – Relative weighting method
    • Considers both the positive benefit of the presence of a feature and the negative impact of its absence.
    • Relies on expert judgment
    • Collaboratively, but led by the product owner, the team assesses each feature being considered for the next release
    • Each feature is assessed in terms of the benefits it will bring if implemented as well as the penalty that will be incurred if it is not implemented. The estimates of benefits and penalties are relative.
    • A scale of 1–9 is used
    • Developers rate the cost of producing the feature and the risk associated with producing it
    • After entering the numbers for all the features, the relative priority for each feature is calculated by considering the percentage of the weighted feature desirability to each feature

Scrum Master

  • a critical role in the methodology
  • helps the team achieve its goals by doing the following
    • Serving the Team
    • Protecting the Team
    • Supporting the team’s use of Scrum
  • Remember
    • A project manager can become the scrum master, if he/she is working in a matrix organization doing the coordination role
    • A line manager (one with reporting authority) ideally should NOT become the scrum master
  • DO
    • Serves the team + Facilitates the team’s interactions – organizes the Scrum rituals and other meetings + Removes the obstacles that are blocking the team
    • Protects the team
      • From interference or disturbances
      • Resolves conflicts
    • Supports the team’s use of Scrum + Provides process guidance – shares best practices, templates, etc. + Audits that the methodology is used correctly + May stand in for the Product Owner in his absence
  • DON'T
    • Manage the team
    • Direct the team members
    • Assign tasks
    • Drive the team
    • Make decisions on behalf of the team
    • Over-rule the team members
    • Direct product strategy

Developers

  • Each member of the team is called a Developer: because they all contribute to the development of the product
  • The team is SMALL (ideally 7 + or – 2)
  • The team is cross-functional: should contain all skills necessary to deliver value to the customer
  • The team is self-managing
  • Building a Scrum team
    • Team members will need to collaborate a lot more
      • Hence look for people who are good at communication skills and team working
    • You need some specialists but more generalists; e.g. Testers who can code
    • You need a team that will make decisions and take responsibility for them
      • Promoting the right attitude
      • Make it “safe” for people to make mistakes
  • Building empowered teams
    • Is:
      • Responsibility and Ownership
      • Working independently towards common objectives
      • Understanding Why so that guidelines can be applied
      • Weighing the impact of decisions on all affected stakeholders
      • Making more trade-off’s, not less
    • Is Not:
      • Throwing out the rule book
      • Bypassing everyone who will say No
      • Doing the “Fun Parts” of someone else’s job
      • Freedom to unilaterally make decisions that impact others

Manager

  • The Scrum life-cycle does NOT mention the "manager" at all
  • The team in Scrum is supposed to be self-managing and is supported by the Scrum Master
  • The team takes directions from the Product Owner in terms of work needed and prioritization
  • So what does a functional or line manager do in Scrum? (Manager 2.0)
    • Play an active role in recruiting right members
    • Be the mentor/coach for the team
    • Bring the right culture into the team
    • Help the team understand the big picture
    • Develop skills - address training needs
    • Administer rewards and recognition
    • Protect the team in prioritization battles
    • Deal with escalated issues
    • Keep abreast of technology, industry and business trends and prepare for the future
    • Represent the team at external forums

Special roles

  • Architect
    • Decides about framework, model, etc
    • Reviews designs, code
    • Comes up with technical roadmap
  • Automated tester
    • Builds framework for test automation
    • Builds suite of automated tests
    • Helps moving towards test-driven-development (TDD)
  • Configuration Manager
    • Maintains cod repository
    • Automates source code control, build and release processes