Point of notice, you are about to read a fictionalised story. The sprint journey to be described is not based on a single job, rather a collection of past experiences, sugared with the odd hat tip to more experienced product owners.
Welcome to project Utop.ia
The goal of this article and its successive nine (!) siblings, is to expose the workings of a scrum team, or more specifically, its sprint routine.
There is one limitation. To explain the inner workings of a successful scrum team, I'm left to my own subjective experiences and reflections. It will be your responsibility to unwarp the lens of this imperfect perspective.
I am a PO (Product Owner). The role of a PO is to know where the experts are, rather then to pretend to be the expert. In that respect, the ability to look at challenges from the perspective of each of your team members -from Sponsor to intern- gives your project that extra edge to survival.
In conventional terms, a Product Owner maintains the backlog. I personally believe that a backlog is but a tiny part of the complete suite of tools you'll wield.
If you are thinking about becoming a PO yourself, take the agile fundamentals in mind. The role is designed as single point of responsibility. Therefore, you'll have to do the jobs of all the profiles your team will be lacking. Because there is no one else to blame then the PO, at the end of the day. As a result, if you believe you can't fulfil that commitment nor convince your Sponsor you need that missing profile of which you are not the suitable placeholder for, you are only left with the option to refuse the job.
On that fun note, allow me to briefly explain the structure of a regular agile sprint, and attached to it, the thread of this series.
Our preferred sprint length is 10 days, which is also how I'll divide the posts for bite-size reading purposes. We usually have about 10 tools or documents to support the sprint, which I'll try to match to each post as well. And last but not least, each sprint team has about 14 stakeholders types, which will just be dropped in at random.
Against common sense, the first day of the new sprint revolves around the last sprint. Even more confusing, the second day of a fresh sprint will be about... the sprints after this one.
Document highlight: The changelog.
Start of day
After a weekend of family instituted offline mode, I'm trying hard to visualise the fine print of last week's demo. That effort is usually as successful as my attempts to sneak some time into a Python pet project on a sunny Sunday. If you don't know Python, that reference was utterly useless.
Luckily we have a changelog later on, to revive memories.
This is our agenda for this fine Monday...
|standup||15 min max|
|Changelog evaluation||Based on the scrum master's changelog, prepare the CI meeting|
|CI Meeting||Present sucessfully finished and failed features to all business stakeholders, agree on upcycle (2 x 2 weeks)|
|User stories||Because your team needs it|
|Last sprint zone|
As ceremony, some teams don't include the PO in the standup. In my humble opinion, having a daily opt in keeps you grounded. However, you need a strong Scrum Master (or the community manager, in the case of one of my latest projects) that can tell you to shut up. Failing my own advice, please try to remain in the background and let the Scrum Master lead.
From a opportunistic angle, standups disrupt your morning planning overview - the perfect excuse to get from under boring meetings you'd otherwise "love" to attend.
Stakeholders: PO (optional), Scrum Master (leader), Tech Lead, Developer, Functional Analyst, Storyteller (optional), Designer (optional) Tester
Undoubtedly one of the most archive oriented tasks, the maintenance of proper changelogs. A task of the Scrum Master, it is also up to the PO to understand the contents and break each topic down, even if it is only based on high level understanding.
This meeting is about getting there. One of the advantages of carving time out for this, is that it helps bringing back the demo, and brings up any gaps the demo forgot to cover. Such as planned backlog tasks that got "accidently looked over" (read: dropped in order to maintain sanity).
Stakeholders: TSM (optional), PO and Scrum Master (leader)
A.k.a. the "CI Meeting", this is the board meeting where reality meets management (politics). Your last three meetings have prepared your cards for this one. The primary target is straight forward and key for the health of your project: present an objective overview of what got achieved during the last sprint, to then leave the responsibility of release approval to business. That's the crux of what this meeting is about. Business decides what should be held back, released in a regular flow or hot-fixed, your job is to guide them away from stupidity - as far as humanly possible. In effect, once a feature or fix is approved for release, the majority of them have an unblocked upstream towards the sea of production.
Use the changelog as your guide through the meeting, if only to show respect to the Scrum Master for keeping records.
Stakeholders: Sponsor (business), TSM, Release Engineer (co-leader), PO (co-leader), Scrum Master (optional), Functional Analyst (optional) and Tester
The agile sprint CI-CD flow is straight forward. Each ending collects a variable number (can be zero) of proposed changes to the project repositories. This collection -a.k.a. the "changelog"- has 4 (!) metamorphoses in its lifetime.
First, it is your reference list for the sprint review demo. This is usually the longest version of the list.
Second, it becomes the short-list of all new features, improvements and refactors avaluated on quality. Some changes won't make the north end of the cut.
Third, the eventual long lifetime of the changelog will be the final cut of changes that made it to the upcycle release. Remarkeably, some entries might move from unsuccessful to successful again, for multiple reasons. Pride of a developer who couldn't resist a weekend nightly, the business Sponsor considering some change "well that's good enough", ...
Lastly, your changelog will be cloned into the perpetual next sprint, because some changes fail and need to be picked up again. This is a normal process, don't feel bad about it (that's the job of your Scrum Master).
Albeit considered a technical document, the changelog is best conserved if it has received some attention for readibilty. In rare moment you might find yourself digging for an old copy.
Document source: changelog
In real life conditions, there might have been a couple of Slack messages through out the day -especially when there is no storyteller around- where your Scrum Master notifies a bottleneck for the odd team member who has been left in the cold when the tickets were handed out.
That's ok, it means your Scrum Master, or more probably you, is still getting into the project and hasn't balanced the feature load. It takes practise.
Even though this article wildly exceeded the intended threshold, allow me to highlight one more important participating scrum profile, the Release Engineer. A special kind of architect, typically with DevOps background. This profile helps tempering your natural urge to hastily release exciting features, just as he/she is your ally in moderating hotfixes requested by business.<< Scrum team overview | Day two - roadmapping >>