A day in the life of a Scrum Team
At Cloudoki we start up projects in Scrum, experienced and novices alike. This mix has allowed us to gather the best experiences and share them with new 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 will 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 intended for onboarding new Cloudoki family members and clients as well.
All readers 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, the company needs to realise its customers are in need for a service that is oriented to them - the user - and not the other way around. Second, that service needs to be defined in a user-centric story and a roadmap planned for early release, not to be perfect. Lastly, a workable framework needs to be set up with competent stakeholders and 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 effect on its chances of success. A competent team, however small, with a single Sponsor (management SPOC / budget overlord) and adequate tools will move a mountain. 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. 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 that is subject to user-driven change, that precious commodity called "customer loyalty" materialises out of thin air and hard team efforts.
Stable, customer oriented feature releases require respect for the scrum framework from all stakeholders. Since scrum is intentionally flexible, the risk of one role leaning too hard on the process exists, but always with consequences down the roadmap.
Scrum concepts
Roles
In "A day in the life of a scrum team", we define 11 team roles, carried by on average 5 to 8 revolving profiles. Logically, most profiles take up more than a single role in the team - and that is to be encouraged. In practise, we tend see bloated teams under-achieve in relative output compared to smaller, boot-strapped ones.
The magic of a good team selection happens by 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.
Tools
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. github.com/Cloudoki/scrum-team-toolbelt
Time-line
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.
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.
Ceremonies
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?
Indifferent if you are about to join a scrum team or learning about the general framework, we'd advise you to select a "persona" (role) next. By looking at the interactions from the point of view of your persona, you'll start to understand who you will be interacting with on a day-to-day basis and which tools are most impactful on your professional life.
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.
To-do
Following entries will be provided over the next weeks and months.
- Product lifecycle explained
Contribute
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.