At Cloudoki we start up projects in Scrum, for experienced and novice teams alike. This mix has allowed us to keep evolving, gather the best experiences and share them with new project teams, each time again.

"The agile scrum" is one of the more successful organisational frameworks and fundamental to our ability to deliver products reasonably within time, with the user on center stage.

Each kind of company and product has its own implementation of agile methods and ceremonies, depending on their size, legacy and market. Since we've worked with all the flavours we think there might be something in our guide, "A day in the life of a scrum team", for any reader.

This guide is based on our collective experiences. We break them down in Roles, Tools, Time-line and Ceremonies. Although your personal mileage may vary, we hope the documentation will bring you some new insights and practical usability to your project - even if it is your first. "A day in the life of a scrum team" is used for onboarding Cloudoki talent and customers, but aims to be helpful for any reader.

You are welcome to promote and contribute to this guide. An interactive (git) tool-belt has been released to support your suggestions and improvements.

Why we scrum

The feeling of having impact is what makes a product team thrive.

To build good products

We might be kicking in open doors here: building a good product is hard.
First, a product team has to shift its perspective to a consumer-first design process. Second, the resulting user stories and roadmap need to be planned for early release, surpressing the urge to deliver a "perfect" product. Last but not least, the competent stakeholders require a workable framework with internal freedom: the agile scrum.

In general, we notice both increased team member happiness as client satisfaction the more experienced we become in agile scrums.

To minimise management

Contrary to some beliefs, throwing money and managers at a project has no measurable effect on its chances of success. A competent team however, with a single Business Sponsor ("SPOC") and adequate tools, will move mountains. A well balanced, happy team capitalises on the confidence it is entrusted - the feeling of having impact is what makes a product team thrive.

An agile scrum team is always a bigger collective of roles than members and never a fixed set-up, the configuration varies per project. At Cloudoki we try to keep our management involvement at 20%.

To keep customers happy

Customers are not helped with a perfect service that never arrives because it's forever stuck in development. By releasing early and maintaining a lean roadmap and hard team efforts, we generate "customer loyalty" that is subject to user-driven change.

There are caveats. Stable feature releases depend on respect for the scrum framework from all stakeholders. Since scrum is intentionally flexible, the effect of one role leaning too hard on the process tends to generate consequences further down the road(map).

Scrum concepts


In "A day in the life of a scrum team", we define 11 team roles, typically carried out by 5 to 8 profiles in the scrum framework of a project. Logically, most profiles take up more than a single role in the team - and that is to be encouraged. In the field, we see bloated teams under-achieve in relative output, compared to smaller and boot-strapped ones.

The magic of a good team selection happens through the Sponsor and the Product Owner, when budget and competences are matched during the scrum team setup.

Roles abbr. entries
Scrum Master SM Manager of the scrum, focussed on the sprint git
Architect Arch Tech lead of the product, usually senior engineer git
Engineers Tech The tech team turning user stories into product features git
Release engineer Release Specialised engineer managing the continuous release pipeline ("CI/CD") git
Tester Test Specialist engineer guarding acceptable product quality git
Functional Analyst Analyst Maintaining the flow and service dependencies of the product git
Story-teller Story Writer of the user stories and feature acceptance criteria git
Product Designer UX Measuring the user needs and translating them into good experiences ("UX") git
Product Owner PO Story-teller and serving leader Day 1, Day 2, Day 3 and git
Product Manager PM Project based "internal" PO (Cloudoki specific) git
Tribe Scrum Master TSM In enterprise tribes, the liaison between product teams git
Sponsor Management point-of-contact and budget overlord git

We encourage you to contribute by sharing your experience in this series.

Scrum Team


The management of a modern team and product entirely depends on matching tools, both organisational as technical. We typically involve about 11 tools in a product scrum. Our list is opinionated, so feel extra welcome to contribute with your preferred tools and experiences.

Tools maintainers entries
Project management PO, SM
Ceremonies runbook SM
Feature roadmap PO, Sponsor git
Wireframes UX, Analyst, Story
User stories Story, Analyst, Arch git
Functional diagrams Arch, Analyst
Sprint planning SM, Tech, Analyst
The changelog SM, Release, Test git
Release plan PM, Release, Arch, Test
CI/CD management Release
End-to-end testing SM, Test

We maintain our scrum team toolbelt reference and repository at GitHub.


The agile development time-line wildly varies per project, but usually starts with customer input, followed by the design phase, some more customer feedback, development and first release - also called "MVP" ("Minimal Viable Product"). We like to apply the "Product Lifecycle" method, read more about this soon.

API Lifecycle

The sprint

The most visible partitioning of the scrum time-line is the "sprint". A sprint is a repeating, fixed amount of time and ceremonies acting as the real muscle of the scrum framework. The sprint is used both as high-level partitioning for the roadmap assessment, as deep level best-effort assessment of the amount of work ("tickets") that can be completed within each given sprint.

Going back and forth between the accuracy of the feature roadmap planning and the accomplished deliveries by the team, allows the Product Owner to adapt and predict realistic outcomes of the product investment.

A sprint in Cloudoki consists of 2 weeks, typically resulting in 9+1 worked days.
The Product Owner articles are broken down in those 10 days, for in-depth insights.


Scrum ceremonies are pre-defined events with a role-based target audience and function. Scrum ceremonies are repetitive in nature, usually linked to the sprint sequence. To keep the management overhead under control, we are quite limiting in the ceremonies, so your mileage may vary. Suggest changes.

Ceremonies frequency stake-holders entries
Stand-up daily or every 2 days SM, Tech, Test, Analyst, UX git
Demo every sprint end All git
Changelog every sprint end SM, Test, TSM, Release, Arch, Analyst git
Retrospective every sprint end SM, Test, Tech, UX, Analyst git
Release meeting every next sprint last day Release, SM, Sponsor, Arch, PO, TSM git
Sprint planning every sprint 2nd week SM, Arch, Analyst, PO git
Sprint refinement every sprint start SM, Analyst, Tech git
Hackfriday every sprint end Friday All git

The ceremonies are broken down in the contributing articles.

What's next?

We encourage our team to write down their persona's experience through a sprint, but we of course have to start somewhere. Below you can find the flow through the sprint from the perspective of a PO.

A day in the life of a PO, day one

If you end a persona's "happy flow" through a scrum sprint and come to the conclusion that your time has come to make career changes, consider applying for a great job at Cloudoki!

About the authors

Rui Molefas and Koen Betsens are the founders of Cloudoki and on constant guard to improve and adapt our scrums.


Following entries will be provided over the next weeks and months.

  • Product lifecycle explained


We would like to invite each member of any scrum team to document their sprint journey and share it with us.

Improvements and elaborations are tracked on GitHub. Please read our contribution guidelines before opening a new improvement request or submitting a reference.

Released articles