A day in the life of a Scrum Team
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).
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.
|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.
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.
|Project management||PO, 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|
|End-to-end testing||SM, Test|
We maintain our scrum team toolbelt reference and repository at GitHub. github.com/Cloudoki/scrum-team-toolbelt
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 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.
|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.
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.
About the authors
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.