Introducing the Small Scale Scrum framework

Introducing the Small Scale Scrum framework

This agile approach is designed for small teams whose members play multiple roles.

Spiderweb
Image by : 
Christian Holmér. Modified by Opensource.com. CC BY-SA 4.0
x

Get the newsletter

Join the 85,000 open source advocates who receive our giveaway alerts and article roundups.

Scrum is a leading candidate for the implementation of Small Scale Agile for many reasons, including its popularity, developers’ preferences, high success rates for scrum adoption and project deliveries, and strong principles and values including focus, courage, openness, commitment, and respect.

Small Scale Scrum can be best described as “a people-first framework defined by and for small teams (a maximum of three people) and supporting planning, developing, and delivering production-quality software solutions.” The proposed framework centers around the concept of team members occupying multiple roles on any project.

Small Scale Scrum is valuable due to its strong support for the small, distributed teams found in organizations all over the world. Small teams need new ways to meet customers’ continuously growing expectations for rapid delivery and high quality, and Small Scale Scrum’s guidelines and principles help address this challenge.

The Project backlog is a list of everything known to be required in the project. It is created before any development work begins and is maintained by a development team. The project backlog contains development tasks and software requirements. It replaces the traditional product and sprint backlogs.

The sprint planning meeting is time-boxed (i.e., set in advance for a specified amount of time) and focused on planning work for the upcoming sprint. The meeting is run by the development team and advance planning is required to keep it concise. Sprint planning is value-based. At this point, requirements that will be worked on in the upcoming sprint should be clear and contain approved acceptance criteria. Capacity, typically measured as velocity, is not used; instead, the team has to take an educated guess. Velocity emerges only after three or more sprints, which is usually after the Small Scale Scrum projects are finished.

The three-people team is comprised of the development team and the project manager (most of the time). The development team is expected to be involved in gathering and clarifying business requirements, doing development work, performing quality testing, and releasing software to the customer.

The proof of concept/demo is a realization of the small work completed in the sprint to showcase progress in development. Any deviations or incomplete work are discussed during the POC/demo.

The sprint review meeting is organized and run by the development team and project manager (if involved in the project) and attended by the customer or customer team. The sprint review is time-boxed and contains demonstrations of sprint work and a short outline of work completed/not completed, bugs raised, and known and/or descoped issues (if any). Customer feedback is gathered at the end of the demonstration and incorporated into future sprints. Very little (if any) preparation is required to keep the meeting short and structured.

The sprint retrospective meeting is organized and run by the development team and project manager (if involved) and may be attended by the customer and/or customer team. The sprint retrospective is time-boxed and requires no advance preparation. Due to the small size of the development team and the sprint builds (with a smaller number of features delivered), this meeting is relatively short. The sprint retrospective takes place after the sprint review and before the next sprint planning meeting.

The sprint review, sprint retrospective, and sprint planning may be combined into a single meeting which we term the sprint termination, lasting approximately 90 minutes. These meetings are concise, structured (thanks to advance preparation), and must not include any unnecessary/unrelated discussions.

The first/final release is the project’s end result. The development team runs the tests, verifies the completed work, confirms fixes, and signs off on the release build.

The Scrum Guide’s recommended time-box guidelines per ceremony should be considered valid for small scale-scrum ceremonies.

A related version of this article was originally published on Medium and is republished with permission.

Download the Introduction to Small Scale Scrum guide


What to read next

CICD with gears

Here's how the scrum agile methodology can help teams of three or fewer work more efficiently.

Topics

About the author

Agnieszka Gancarczyk - Agnieszka is an Associate Consultant working for Red Hat App Dev Center of Excellence and developing software solutions for customers in small 1-3 person Agile teams. She spent a year researching Small Scale Scrum for her final thesis and has recently graduated with MSc in Computing (Communications Software). Apart from software development, her interests lay in project and people management.

About the author

Leigh Griffin - Leigh is an Engineering Manager and Agile Coach working for Red Hat. This role allows him realise his passion for Coaching and helping individuals and teams improve how they work on a day to day basis.