German Flores

Chicago, Illinois

Chicago Illinois

Morning ride, cool but sunny. 30 miles 17F

For any meeting

Who’s meeting is this? A simple checklist

Car & Team Analogies

“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

This Is the Time

I have a job, stable family life, health. This is the time to think ahead, put the effort in, work on the big thing.

Not Convinced I Should Attend

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

  • What questions do you have?
  • Why do we need to meet?
  • What problem are we meeting to solve?
  • How should I prepare for this conversation?
  • What is the agenda?
  • What decision are we meeting to make?

Small Software Development Teams

Besides a lower capacity there other downsides to small (e.g. three) engineering teams.

  • Coverage, e.g., Depending on the work they are doing and applications they support there is a risk of not having enough folks to provide support during a crisis while continuing iteration development, then add someone being out sick, and someone on vacation and velocity and morale tank. You can mitigate by staggering vacations but not much you can do about people being sick or bugs
  • People moving on. The proverbial getting hit by a bus situation where someone in the team leaves, and now you are down to only two people
  • Onboarding efficiencies. Supporting the onboarding of a new engineer is much easier and takes less time when you an optimal sized team
  • Engineering progression. It is likely that there will be more instances in a larger team for folks to develop their leadership skills than in a smaller team. The larger the team, the more capacity, i.e., more variation of work, which in turn exposes engineers to more types of problems to solve
  • Scale. If we are staffing our teams with the three roles: Development, Product Owner, and Scrum Master having a group of only three means that the Product Owner role and Scrum Master role will have additional time. Not a downside, just an adjustment for the smaller group

Workplace Fiction

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

What Is a Story

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.

Components of a Story

Why We Write Stories

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.

Story Titles

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.

Acceptance Criteria

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.

Acceptance Criteria Characteristics

  • Set of statements, each with a clear pass/fail result
  • There is no partial acceptance: either a criterion is met, or it is not
  • They must be actionable
  • Criteria should be independent of the implementation
  • Helps the team deliver
  • Helps the team build or implement QA tests
  • Helps the Product Owner perform User Acceptance Testing
  • They are not the technical details or steps for completing a story
  • They are not the equivalent of how the story will progress through User Acceptance Testing

Implementation Details

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 We Do Not Write Stories

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.

Chores/Tasks Characteristics

  • Chores/Tasks can include acceptance criteria for clarity
  • Receive zero story point value
  • Typically used for documentation or straight forward work

How We Use Stories in the Technology Team

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.

When I Watch Youtube Videos With The Kids

I watch these and I thought you might like them:

What Does The Scrum Master Role Do in a Team?

What do folks in the Scrum Master role do in Leapfrog Technology Teams?

  • We ensure and facilitate the Scrum. When I say to ensure, we ensure that Stands, Story Writing & Estimation, Retrospective, and Planning sessions happen and are effective and efficient. We have recent evidence that when teams operate with parts of the Scrum framework, they deliver software.
  • Champion and protect the team. We know that when teams have good working conditions and focus they are happier.
  • Surface situations in the team to team leads or leadership. Sometimes I ask is that a thing? Sometimes it is a thing, and sometimes it is not a thing.
  • We care about delivery during the sprint. We ideally find and share with the team opportunities to work efficiently.

There’s a lot more depending on your experience and level of the role, but the above is a beginning expectation.

The Way I talk about Scrum

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.

Backlog Refinement

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.

Minding the Team Expectations for Folks in the Scrum Master Role

For folks new to the Scrum Masters role, I am not expecting expert knowledge on Technology, Scrum, or Software Development.

I am expecting:

  • Follow through
  • Work ethic
  • Effort
  • Attitude
  • Passion
  • Being coachable
  • Doing extra
  • Being prepared
  • Curiosity
  • Not to procrastinate and to ask when unclear
  • Being authentic so we can make progress and talk about the areas that you need growth on

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.

Why We Write Stories

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.”

We Write Stories

  • To articulate and communicate requests for work
  • To be transparent about what we are working on
  • To ensure people asking the work and people doing the work are aligned
  • As a placeholder for people to have conversations
  • To mitigate building the wrong thing
  • To break work down into deliverable pieces and identify dependencies
  • To have discipline around capturing the what and why
  • Self-discipline. Don’t take on too much. Deliver one thing at a time
  • So the team is aligned with the work and help in case someone is sick
  • Keep track and understand how much effort we are spending on initiatives
  • Define what the team will deliver every two weeks
  • To have useful Stands aligned on stories the team is working on
  • To reflect on the work we produced in team Retrospectives

We Do Not Write Stories

  • For when having a conversation and agreement is faster and easier than writing a story
  • For process sake
  • Because Workfront is fun to use
  • To compete with other teams
  • To show managers we are busy
  • To manage people

Favorite tracks 2016…

Simon Sinek Understanding The Game We're Playing - One of my favorite videos of the year

psychological safety…