As a dev team accelerator, we work with many Silicon Valley technology start-ups helping them to create a natural extension of their software organization. A critical factor in our success is in a well-structured division of labor across distributed locations. In practice, that means engagement of Product and Development Management leaders in North America backed by an extended dev team in Europe, 7-10 hours ahead.
The majority of our clients and partners are devoted practitioners of The Agile Manifesto – from individual and interaction levels, through to collaboration and effective response to change. As a result of our experience across dozens and dozens of projects and running thousands of sprint cycles, we’ve found the following structure to be most effective.
Timing is everything. Experience has demonstrated using a clearly-structured cadence, with set rhythms and tools for communication, ensures all members of the project team can deliver high-quality results on the daily.
Scrum as Applied Agile
Scrum processes enable organizations to adjust smoothly to rapidly-changing requirements and produce a product that meets evolving business goals. An agile Scrum process benefits the organization by helping it to:
- Increase the quality of the deliverables
- Cope better with change (and expect the changes)
- Provide better estimates while spending less time creating them
- Be more in control of the project schedule and state
A critical factor in the success of our work with clients is in a well-structured division of labor across geographies. In practice, that means engagement of Product and Development Management leaders in North America backed by an extended dev team in Europe, 7-10 hours ahead.
A Scrum process is distinguished from other agile methods by specific concepts and practices, divided into the three dimensions of Time Boxes, Roles, and Artifacts. Let’s focus on each of these and the part they play. We’ll then show how Scrum Events converge into a sustainable teamwork playbook.
Want to see how it all fits together without understanding the moving parts first? Skip to the last section below.
Time Boxes: Following the Sun
First off, this means working normal hours wherever people are across the planet, for continuous productivity and resilience (and no less critical, avoiding burnout). Thanks to our experience executing dozens and dozens of projects, run through thousands of Sprint cycles, we’ve found the following structure to be most effective:
|Days||Day 1||Day 1 – 9||Day 3||Day 9||Day 10|
|Sprint planning meeting||Daily stand-up||Grooming meeting||Sprint review||Sprint retrospective|
|Time||8:00am US||11:00am GMT||8:00am US||8:00am US||8:00am US|
Time boxes differ from other dimensions of our Scrum working model in that they are not really optional. Despite what Einstein calculated about the rest of the universe, time here on earth works quite well as a constant. Sticking with a schedule, even working around holidays and other out-of-band events, helps cement team accountability to product deliverables and the customers that they are delivered for.
While it’s essential never to take consensus for granted, teams work better when roles are clearly and universally understood. Our teams are built around a Product Owner, Development Team and Scrum Master
- Product Owner
The project’s key stakeholder and represents users, customers and others in the process. The product owner is often someone from product management, a key stakeholder, and/or a key user. The Product Owner is responsible for continuously communicating the vision and priorities to the development team. At the same time, Product Owners must be available to answer questions from the team. Depending on the size of the project, they may have varying degrees of direct customer and stakeholder engagement
- Development Team
Responsible for self-organizing to complete work. A Scrum development team contains about seven fully dedicated members, ideally in one team room protected from outside distractions. A typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. The team has autonomy and responsibility to meet the goals of the sprint.
- The Scrum Master
Responsible for making sure the team is as productive as possible. The Scrum Master does this by removing impediments to progress, by protecting the team from outside, and so on. The Scrum Master does not manage the team.
Key Sprint Tools and Entities: Practical progress
Culture and communication and collaboration are abstractions made effective by translating them into practice. In the context of Scrum, this works on two levels: first, an agreed-upon set of artifacts for structuring signals among members of the team, and second, capturing shared understanding for a shared commitment to results.
Across most all our projects, we use Jira for issue tracking, for bug tracking and Agile product management. (We also use Microsoft DevOps, Slack, Zoom, and just about any collab tool you might name.)
- The story
A user story is an issue type in Jira that acts as the primary method of conveying requirements to the developers/development team. It’s a short, simple description of a feature in the system under development told from the perspective of the person who desires this new capability.
- Product Backlog & Sprint Backlog
The backlog is like a to-do list for your next-gen Software project. It’s a dedicated space for keeping track of tasks that you want to do in the future (and if you’re sick of keeping all your to-do’s in a column on your board and pretending that it’s more than just a list).
There is a crucial distinction between a product backlog vs. a sprint backlog. The product backlog represents a range of aspirations for what the product will do in the future. The sprint backlog represents a time-bound increment of work to bring your product closer to realizing its aspirations.
By definition, the sprint backlog is much more precise and constrained than a product backlog. These two backlog types are maintained in parallel, in order to effect an ongoing translation between the work you need to do next and the work you need to do eventually. Many people confuse the two, leading to poorly-defined product aspirations crammed into a time insufficient to realize them. By the same token, it’s important that any particular issue that makes it onto the sprint backlog ties to deliverable progress against some part of the product backlog.
- Jira Sprint Board
For straightforward story & status tracking, we use the Jira Sprint Board
There are many additional artifacts and process progress indicators that work. We’ve tried just about all of them. The truth is they work in varying degrees depending on the company whose product we are building, and the goals for the product roadmap. If there’s something that works for you, we’re all ears.
Convergence: Scrum Events
Across our projects, we put teamwork into play by combining time boxes, roles, and artifacts through scrum events. That means we work iteratively through each of Grooming Meeting, Sprint, Sprint Planning, Daily Standups, Sprint Review, and Sprint Retrospective.
- Grooming Meeting
Grooming (or refinement) is a meeting of the Scrum team in which the product backlog items are discussed and the next sprint or sprint cycle is prepared. Product grooming is critical in product management because it means keeping the backlog up to date and getting backlog items ready for upcoming sprints. Backlog grooming is often named pre-planning. The product owner and the team arrange this every week. The grooming involves splitting big items into smaller ones, rewriting backlog items to be more expressive, deleting obsolete or no longer needed items, and so on. Also, during the Grooming Meeting, the team size the story and estimates it as a story point (we use the Fibonacci sequence for that).
a time-box of one week to one month during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. We’ve found two weeks works best in most cases.
- Sprint Planning
A time-box generally held on the first day of a sprint where the team decides “what” to complete during the sprint from the product backlog and defines a sprint goal.
- Daily Stand-ups
A 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. The Daily stand-up (aka “Daily Scrum”) takes place is held every day of the sprint.
- Sprint Review
Generally, a one-hour meeting on the last day of a sprint where the team presents the shippable version of a product to stakeholders and discusses, story by story, what was completed during the iteration. All stories are discussed one at a time, paying close attention to the acceptance criteria. In addition, the demo for the new product version is showing.
- Sprint Retrospective
Our teams hold Sprint Retrospective after each Sprint Review and prior to the next Sprint Planning. During this critical structured ritual, the team should answer the following questions:
- What went well during the sprint?
- What went wrong?
- What should we do differently during the next sprint?
Bird’s eye view: the Sprint Cadence
Now let’s look at the whole picture together and see the scrum methodology in practice in a complete incremental cycle. Generally, our sprints last ten working days. Here is the summary description of sprint milestones that we use:
|Day 1 – Day 10|| |
|Day 3 – |
|Day 5 – |
|Day 1 – |
See more about how we execute agile for distributed development here. It’s a key part of the five essential steps that make the UpTeam Dev Accelerator the proven choice for software development momentum to drive business growth.