For any meeting sethgodin.typepad.com
Who’s meeting is this? A simple checklist
“Your engine light came on for a reason, and these things do not fix themselves. Often engine lights come on because something in the engine failed at least three times”, the mechanic replied. “Just because the light is off does not mean that the problem has fixed itself.”
– Ken Doyle
I have a job, stable family life, health. This is the time to think ahead, put the effort in, work on the big thing.
Today I received a meeting request that did not convince me that I should attend. This is how I responded before accepting the meeting:
Could you help me understand why we need to meet? The title of the meeting does not help me
Besides a lower capacity there other downsides to small (e.g. three) engineering teams.
Fiction can help us here, this time in its form, not its content. It can help us to clarify our own thoughts, help us test our ideas before we build them, and help our teams stay focused on the things that matter.
Resources (Science) Fiction and Design
On a previous post titled Why We Write Stories I took a light-hearted approach to the value we get from writing stories, in this post I want to write about why we write stories, the components of a story, when we don’t write stories, and how we use stories in our Scrum implementation at Leapfrog.
Let’s start with “why” we write stories.
Stories are a ‘simple’ format to articulate and communicate requests for work; they can also be a placeholder for people to have conversations about work.
Stories also provide a common language for folks to align and have an agreed definition of done. They mitigate sticky situations of “that is not what I asked for” or “I forgot to add this to the request.”
Acting Agile does not mean evergreen or daily changing requirements, it means building and delivering software incrementally, reflecting, and learning.
Stories help the team gain a shared understanding of the work and reach a shared definition of “done.” Stories are foundational in estimating and when the team plans work.
The title should describe an activity. Let the story name be the starting point for determining what “done” looks like. Ideally, the story title should describe actual behavior by a person in the system.
As a <person/role>, I want <goal>, so that <reason>.
Stories provide us with the person or the role that is making a request, the feature or requirement the business wants, and the problem solved. Stories should encapsulate what the business wants and why it is of value.
A story is not “done” unless the Acceptance Criteria is met, or the team and Product Owner have agreed that the criteria have changed since the commitment to the story.
Some of our teams prefer implementation details for additional details or guidance on delivering the work, but these are always defined and written by the development team. Sometimes they are non-obvious system complications, a sequence of events needed to complete the story or comments from the discussion of the story that the development team needs for reference during development.
When the work is either too small or does not fit into the story format, in those cases, we write Chores/Tasks.
“As a <>, I want <>, so that <>.
We write chores/tasks because it is work that needs prioritization and visibility and to add to an iteration. It may be a stepping stone to get a story to “done,” or it could be a cleanup task that needs attention.
We use stories to break down work into demonstrable pieces of work that we can then estimate and plan for our teams to deliver valuable software to the business.
I watch these and I thought you might like them:
What do folks in the Scrum Master role do in Leapfrog Technology Teams?
There’s a lot more depending on your experience and level of the role, but the above is a beginning expectation.
The last few years in the Scrum Master role my perspective about Scrum related words has changed. Here are a few words that I’m trying to change in my vocabulary when I’m teaching others about Agile philosophies and the Scrum framework.
Instead of Sprint I prefer iteration. Sounds and reads more sustainable. Teams iterate on work every two weeks.
Instead of Planning I prefer forecasting. Sounds realistic. The team forecast work they believe they can deliver over the next two weeks. Things change, a forecast changes.
Instead of rituals, e.g. Scrum rituals I prefer Team Meetings. Ritual sounds too religious, cultish.
When a team is in a bad situation I ask myself, is this sustainable.
Instead Backlog Grooming I’ve been using Backlog Refinement and Backlog Discovery. Every week the team refines the backlog or they discover and ideate about features or problems that exist at the Epic level.
For folks new to the Scrum Masters role, I am not expecting expert knowledge on Technology, Scrum, or Software Development.
I am expecting:
Across-the-board, the Technology Team I work for, exhibits these behaviors which in turn sets the expectation for how I operate and inspires me to be the best in the role. This cycle of expectations across roles is what keeps me engaged, challenged, and coming back to the job every day.
I set these expectations because I care, I care for the person growing in the role and I care for the teams they support. If I don’t care mediocrity seeps in.
In the Leapfrog Technology Team, we use the Scrum framework method to deliver software. The Scrum framework has an artifact called “Stories” sometimes also referred to as “User Stories” too. Stories represent work, the “what” and the “why.”