Tudor Vulpe

SCRUM Methodology in 100 words

Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time. It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month). The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features. Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.

 

The SCRUM methodology has been used for:

  • Commercial software
  • In-house development
  • Contract development
  • Fixed-price projects
  • Financial applications
  • ISO 9001-certified applications
  • Embedded systems
  • 24×7 systems with 99.999%
  • Video game development
  • FDA-approved, life-critical systems
  • Satellite-control software
  • Websites
  • Handheld software
  • Mobile phones
  • Network switching applications
  • ISV applications

Characteristics

  • Self-organizing teams
  • Product progresses in a series of month-long “sprints”
  • Requirements are captured as items in a list of “product backlog”
  • No specific engineering practices prescribed
  • Uses generative rules to create an agile environment for delivering projects

 

Sprints

A sprint (or iteration) is the basic unit of development in the Scrum methodology. The sprint is a time-boxed effort; that is, it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month, with two weeks being the most common; a constant duration leads to a better rhythm and a much more precise prediction about “what’s coming” next from the team members. The product is designed, coded and tested during the sprint.

There should be no changes during a sprint. Each sprint starts with a sprint planning event that aims to define a sprint backlog, identify the work for the sprint, and make an estimated forecast for the sprint goal.

 

The SCRUM Framework

ROLES

  • Product Owner
  • Scrum Master
  • Development Team
  CEREMONIES

  • Sprint Planning
  • Sprint Review
  • Sprint Retrospective
  • Daily Scrum
  ARTIFACTS

  • Product Backlog
  • Sprint Backlog
  • Charts

Roles

There are three core roles in the Scrum framework. These are ideally co-located to deliver potentially shippable product increments every sprint. Together these three roles form the scrum team. While many organizations have other roles involved with defining and delivering the product, Scrum methodology defines only these three.

Product Owner

The product owner represents the product’s stakeholders and the voice of the customer, creates roadmaps, is accountable for the backlog, and maximizing the value that team delivers to the business. The product owner should focus on the business side of product development and spend the majority of their time liaising with stakeholders and should not dictate how the team reaches a technical solution.

Key responsibilities:

  • Define the features of the product
  • Decide on release date and content
  • Be responsible for the profitability of the product (ROI)
  • Prioritize features according to market value
  • Adjust features and priority every iteration, as needed

The Scrum Master

The scrum master helps to ensure the team follows the agreed processes in the Scrum framework, often facilitates key sessions, and encourages the team to improve. The role has also been referred to as a team facilitator or servant-leader to reinforce these dual perspectives.

Key responsibilities:

  • Represents management to the project
  • Responsible for enacting Scrum methodology values and practices
  • Removes impediments
  • Ensure that the team is fully functional and productive
  • Enable close cooperation across all roles and functions

The Development Team

The development team is responsible for delivering potentially shippable product increments every sprint (the sprint goal).

Key responsibilities:

  • Typically 5-9 people
  • Cross-functional: programmers, testers, UI/UX designers, etc.
  • Teams are self-organizing

 

Ceremonies

Sprint Planning

SCRUM Methodology Planning Meeting

Key features:

  • Team selects items from the product backlog they can commit to completing
  • Sprint backlog is created
    • Tasks are identified and each is estimated (1-16 hours)
    • Collaboratively, not done alone by the ScrumMaster
  • High-level design is considered

 

Example:

 
As a vacation planner, I want to see photos of the hotels.
  • Code the middle tier (8 hours)
  • Code the user interface (4)
  • Write test fixtures (4)
  • Code the foo class (6)
  • Update performance tests (4)

The Daily SCRUM

Any impediment (e.g., stumbling block, risk, issue, delayed dependency, assumption proved unfounded) identified in the daily scrum should be captured by the scrum master and displayed on the team’s scrum board, with an agreed person designated to working toward a resolution (outside of the daily scrum). No detailed discussions should happen during the daily scrum.

Key features:

  • Parameters
    • Daily
    • 15-minutes
    • Stand-up
  • Not for problem solving
    • Whole world is invited
    • Only team members, ScrumMaster, product owner, can talk
  • Helps avoid other unnecessary meetings
  • Everyone answers 3 questions:
    1. What did you do yesterday?
    2. What will you do today?
    3. Is anything in you way?
  • These are not status for the ScrumMaster; They are commitments in front of peers

The Sprint Review

Key features:

  • Held at the end of each sprint
  • Team presents what it accomplished during the sprint
  • Typically takes the form of a demo of new features or underlying architecture
  • Informal
    • 2-hour prep time rule
    • No slides
  • Whole team participates
  • Invite the world

Sprint Retrospective

Key features:

  • Periodically take a look at what is and is not working
  • Typically 15–30 minutes
  • Done after every sprint
  • Whole team participates
    • ScrumMaster
    • Product owner
    • Team
    • Possibly customers and others
  • Start / Stop / Continue – The whole team gathers and discusses what they’d like to:
    • Start doing
    • Stop doing
    • Continue doing

Product Backlog

The product backlog is what will be delivered, ordered into the sequence in which it should be delivered. It is visible to everyone but may only be changed with the consent of the product owner, who is ultimately responsible for ordering product backlog items for the development team to choose.

Key features:

  • The requirements
  • A list of all desired work on the project
  • Ideally expressed such that each item has value to the users or customers of the product
  • Prioritized by the product owner
  • Reprioritized at the start of each sprint

Example:

Backlog Item Estimate
Allow a guest to make a reservation 3
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a reservation. 3
As a hotel employee, I can run RevPAR reports (revenue-per-available-room) 8
Improve exception handling 8
30
50

Managing the Sprint Backlog

The sprint backlog is the property of the development team, and all included estimates are provided by the development team. Often an accompanying task board is used to see and change the state of the tasks of the current sprint, like to do, in progress and done.

Key features:

  • Individuals sign up for work of their own choosing
    • Work is never assigned
  • Estimated work remaining is updated daily
  • Any team member can add, delete or change the sprint backlog
  • Work for the sprint emerges
  • If work is unclear, define a sprint backlog item with a larger amount of time and break it down later
  • Update work remaining as more becomes known

Charts

Sprint Burn-down Chart

Scrum Methodology Burn-down Chart

The sprint burn-down chart is a public displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference.

Release Burn-up Chart

The release burn-up chart is a way for the team to provide visibility and track progress toward a release. Updated at the end of each sprint, it shows progress toward delivering a forecast scope.

Conclusion

The Scrum methodology is designed to optimize team satisfaction and productivity, product quality, responsiveness to customers, and transparency for stakeholders. The key practices that enable these benefits include de-emphasizing work on non-deliverable items, implementing and finishing each Story in a Sprint Backlog in rank order, working in short Sprints of 2-4 weeks, and making past, present, and future project information available to all stakeholders.

So, when starting a new project, not only a Software Project, SCRUM methodology can most likely be suitable for you. It helps you organize your work and also have a feedback discussion with your clients/peers. 

Leave a Reply

Your email address will not be published. Required fields are marked *