Why Your Scrum Team Needs a Release Plan

Scrum Release Plan Sets Expectations with Management

When teams transition to Agile Scrum, they may decide the only required planning is Sprint Planning. These teams feel that because they are Agile, they don’t have to plan beyond the next Sprint boundary.

Most of us work in a corporate world, where upper management wants to know when the project is expected to finish and the estimated completion dates for major features and interim deliverables. Since these managers’ budgets pay our salaries, we need to find Agile ways to plan projects and deliver them using Scrum.

Teams that plan for Feature releases can still remain true to Scrum. Both the Scrum Alliance and Agile Alliance mention release planning, but they don’t provide a process to accomplish the task.

For this reason, several methodologies have sprung up to fill the gap and put a project management wrapper around Scrum. The biggest players are Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD) and Large Scale Scrum (LeSS).

To be honest, when I look at those websites, I get dizzy trying to read their process diagrams. The processes don’t feel very Agile at all.

At GSD Mindset, we are big proponents for creating a Release Plan, but we advocate an approach that more closely aligns with Agile and Scrum.The top half of the GSD Scrum Funnel© illustrates our approach.

GSD Agile Scrum Funnel

GSD Scrum Funnel

Simplify the Release Plan Process

  • Divide the application into logical Feature Sets or Epics (in Scrum terms)
  • Break down each Epic into completed deliverable Components
  • Prioritize the Components
  • Organize the Components into a Quarterly Release Plan
  • Start writing Stories for 1st Sprint
  • Release Component functionality and pivot as customers use the product

Most people get the concept of identifying the high-level Features or Epics. From here, Scrum expects the Product Owner to start writing Stories about tiny slices of functionality required to build the Epic. Most new Product Owners find it difficult start with the concept of a completed Feature and immediately know what Stories to write. The intermediate step of breaking down an Epic into its Component deliverables fills the gap.

Prioritize Component Deliverables for Each Epic Before Writing Stories

Once every Epic has been broken down into Components, you can group those Components into Quarterly Releases. There are many prioritization techniques. My personal favorite is defining the Minimum Viable Product (MVP) or Minimum Marketable Feature set (MMF). Think as if you could lose funding if version 1 of the product does not meet customer needs by the end of the first quarter.

If you only have one quarter to prove the value of the product, then what must be delivered? This is a very real concern if you work at a startup or a company with budget constraints. Going through this exercise helps ensure your team delivers the highest value Components first.

Once you know the highest value Components, it’s much easier to write Stories and plan for the first Sprint.

Status Report Against Release Plan

Now, even without knowing your team’s Velocity, you can provide upper management with a Quarterly Release Plan or the list of Components your team plans to deliver each quarter. The team can status report against the plan. Once you know your Velocity, you can size the Components and begin reporting percent complete.

For more details on the GSD Mindset simplified approach to developing a Release Plan, check out:

I’d love to hear about your team’s approach to planning.
Do comment.



Cynthia Kahn

Cynthia Kahn


Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

We are Agile. We are Not Perfect.

Every Team Practices Agile Differently

People take time off. I’m an Agile Scrum Master and Coach to a new team in their third sprint. Newbies. I fretted when I realized that I had a mandatory 2-day class scheduled on the same days as my upcoming Retrospective and Sprint Planning sessions.

At the first Retrospective, the team agreed that they really liked Scrum. At the second Retrospective, they felt like they were getting the hang of it. So, I asked the team if they wanted to run Retrospective on their own, because I knew they would not want to give up two days of their Sprint.

After a short discussion, the team decided to handle it themselves. Canceling Retrospective and holding Sprint Planning on Day 1 of the next Sprint was not even discussed as an option.

I got a little teary-eyed when I realized that sometime in the last 6 weeks my team became self-managing.

For the third Retrospective, they truly own it!

Do I think the team will conduct Retrospective and Sprint Planning with the same rigor as when I run it? Not really, but I am excited to see the result anyway.

Teams Learn by Doing

As you know, shifting from more traditional methods to Scrum and adopting an Agile Mindset takes practice. Scrum is a different routine and requires a higher level of commitment than many teams are used to. The change in habits and thought processes comes from experiencing what it’s like to Sprint, accepting mistakes as inevitable and reinforcing through example.

In the beginning:

  • My team didn’t even know what Stories to write.
  • The team’s first Stories were not really Stories and they required extensive grooming. (They still require grooming.)
  • A couple team members’ Standup attendance was spotty, until they began to see the results of daily focus on getting work done.
  • Not all Stories closed, because the process was new and the team needed to understand about relative sizing, Story Points and Velocity through their involvement in actual Sprints.

Experience provides context. Reinforcement creates good habits.  

Every Team Practices Scrum in their Own Way

As Scrum Masters and Coaches, we not only need to understand Scrum and how to effectively communicate its principles, we need to recognize the team needs the freedom to practice Scrum in the way that produces the best results.

Scrum prescribes 4 formal events for inspection and adaptation:

  1. Sprint Planning
  2. Daily Scrum (Standup)
  3. Sprint Review (Demos)
  4. Sprint Retrospective

As a professional with experience on multiple Scrum teams, I have seen teams within the same company practice Scrum differently. This happens even if all the teams receive training and coaching from the same Coach. Even timing of events can vary.

It’s a good thing for the team to take ownership of the way they practice Scrum. Ownership enforces accountability.

It’s OK if it’s not perfect.
How do you know if good is good enough?

Ask these 2 important questions:

  1. Is the team able to predict and meet it’s time-boxed Sprint commitments?
  2. If team size remains constant, is Velocity averaging out?

These two factors are crucial to delivering projects on time.

If you answered “Yes” or “Most of the time” to both questions, your team is doing well.
If you answered “No” to both questions, brainstorm improvements at Retrospective.

It’s not about perfection.
It’s about Getting Stuff Done (GSD).

What are your experiences?

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500


read more

Don’t Hate Me Because I’m Agile

Why Do Traditional Project Managers Hate Agile?

I recently hired into a project management group of mostly traditional lifecycle project managers. The group has a directive to transition the team to become agile. That’s why I’m here.

I’m also here to apply agile to the Phase III of a problem project, where Phase I and Phase II were mismanaged and the application is unstable. So much for traditional project management methods.

In the first month since I started: I setup JIRA, formally kicked off the project with the Steering Committee (we can still be agile in a waterfall world), provided 2 half day workshops for my business product owner and business team members, planned feature deliverables for six Epics over the next three quarters, planned and executed my first sprint. We are not in “Exploring,” we are in “Doing.”

I attend all the project manager team meetings. I participate in discussion. I even offered to train or coach any project manager interested in becoming more agile.

Last week, my boss tells me that another project manager needs help with an agile project, and he asked me if I’d be open to coaching him. Of course! Next day, my boss sends out an email giving him the green light to reach out. Nothing. A few days later, my boss asks me if that project manager contacted me, and I had to admit that I had not heard from him.

This morning, I’m sitting at my desk and another project manager comes up to me and says, “Yesterday, I was sitting at my desk and I was surprised to hear you talk dirty.” I smiled and asked him to explain. His reply saddened me and inspired me to write this post: “You know, I heard words like agile and scrum in your conversation.”


I get it. Everyone’s a little scared of change. People ignore or belittle things they don’t understand.

I get it. Agile is not only a new method of application development, it’s a new way of thinking.

But, as technical professionals, we must learn new things all the time to remain relevant in our jobs.

What makes learning and adopting agile different from everything else?

I don’t have one best answer, but my observations lead me to believe that if you really want your team to become more agile:

  • The desire to change must come from upper management and it must be embraced throughout the organization.
  • Everyone must be trained. Get good training, even coaching. It’s worth the money.
  • Rip off the bandaid and do it right. If you want to practice scrum, practice scrum. Every aspect. Don’t hybrid a method unless you’ve mastered it.
  • Start small, with teams that want to transition first. Find the early adopters. Use them as poster children for how amazing agile can be.
  • Integrate change management principles into the transition. I attended a webinar on this topic the other day, and it opened my eyes to new ideas about how to implement agile (topic for another blog post).

I can hear you thinking: That’s all fine and good, Cynthia, but what am I supposed to do? I’m just an individual contributor, the Scrum Master / Product Owner / Member of the Development Team.

I say: Walk your talk. Seek to understand. Lead by example.

  • Meet individually with those who resist and ask them how they feel about agile. Elicit honest feedback. Listen. Don’t judge or try to change their minds at this meeting. Afterwards, use that valuable feedback to figure out how to address concerns.
  • Ask those who are struggling if they’d like to observe you work with your scrum team.
  • Offer to coach those who have trouble shifting their mindset, writing stories, grooming stories and sprinting.
  • Help your team meet their sprint commitments, even if it means working outside your job description.
  • Deliver quality product to the customer more quickly than before, even if it means helping with testing.

Agile is a journey.

Retrospective ensures continuous improvement.
We can always make it better if we work together as a team.

Is that so different from anything else we do?

Don’t let negative experiences like the ones I describe sidetrack you.

Smile big and be the change you want to see in others.

I wrote this post to spark a discussion.
What are some techniques you employ to reduce resistance to adopting agile?

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

Write Better Stories

The 5 Key Ingredients to Write Better Stories

Every time we teach a GSD Scrum Training workshop, one of the most difficult concepts for students to grasp is how to write a story.
On the surface, the concept seems quite simple:

Describe the user’s functional requirement from their point of view and include acceptance criteria, so quality assurance testers know the finished product meets the user requirement.

The story and acceptance criteria format below looks simple enough, right?

Story format:
As a <user role>
I want <to perform some function>
So that I can <achieve some goal/benefit/value>

Acceptance criteria format:
Given that <I am able to perform the new function>
When <I complete the function>
Then <something happens to show success/failure>

Then, why do so many people have trouble writing stories? We think it’s because scrum assigns the Product Owner responsibility for writing the stories, and most Product Owners have never written functional requirements. That’s why we recommend scrum teams include a Business Analyst or Systems Analyst to work with and train the Product Owner.

Even if an analyst helps write the stories, a story is a very specific type of functional requirement. I like to compare it to a mini use case. The story begins with an event and follows a process through to a successful or unsuccessful outcome.

Well-written stories meet the following criteria:

  1. Stories deliver a completed slice of working functionality.
  2. Stories describe the user experience, not how to build it.
  3. Stories contain clear functional requirements and acceptance criteria.
  4. Stories are small enough to be completed within the time allotted to the sprint.
  5. Stories do not leave the application in an unstable state.

An example high-level use case would be Customer Account Maintenance. A good way to identify the stories that comprise this use case is to brainstorm all the reasons that a customer would access the application to execute this module.

Some candidate stories for Customer Account Maintenance:

  • Create a New Customer Account
  • Update Customer Account Information
  • Change Forgotten Password
  • Retrieve Forgotten Username

Each candidate story is a single slice of functionality that represents a small slice of the overall functional requirement. Each story requirement is small, so it can be completed within the sprint boundary. The team can start by implementing Create a New Customer Account, and then add the new functionality described in the other three stories at any time. That’s because each story can stand on its own and, if described correctly, will not leave the application in an unstable state.

Let’s write a story together. We want to be sure to clearly describe the user experience and quality assurance criteria. Although traditional scrum says that acceptance criteria are optional, we disagree. Everyone needs to understand both the requirement and how to tell if the product works as intended.

A well-written story for Update Customer Account Information:


As a customer
I want the ability to update the personal information on my account
So that I can keep the system up to date and continue to receive timely statements and product offers.

Acceptance criteria 1:
Given that I have previously logged into the system
When I access the personal information update page
Then I am able to update my first name, last name, address, phone number and email address

Acceptance criteria 2:
Given that I have updated my personal information
When I click Save
Then the system checks the validity and format of the data entered. If there are no issues with the entered data, the system updates the database. If there are issues with the data, the system displays an appropriate error message(s) and does not update the database.

The requirement is clear. Everyone understands what the customer wants to do and what information is considered personal account information. In addition, the application validates the customer entry, so invalid data does not get saved to the database to ensure data integrity.

The completed story for Update Customer Account Information meets all our criteria and, if it passes quality assurance, it could be moved to production at the end of the sprint.

Another thing to keep in mind is that the story’s requirements cannot depend on another team to perform work in order to close it. If a high-level use case contains functional requirements with dependencies across teams, the Product Owners of the affected team must clearly divide the experience into independent functional descriptions.

Once you understand the rules, the art of story writing becomes more straight-forward. Be sure to read and review each story at Story Grooming before sizing, so everyone on the team understands the requirement.

Want to better understand how to successfully practice scrum in the real world?
Then you should read our GSD Scrum Handbook.



Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

3 Tips to Close More Stories

Want to Close More Stories on Your Scrum Team?

The scrum team’s job is to decide how many story points to bring into the sprint, determine the right stories to accept into the sprint backlog, and close all stories in the sprint backlog by the end of the sprint. Most scrum teams think they know their velocity or how many story points they can complete in a sprint. They also do a pretty good job of prioritization, so they bring in the right stories.

Then, how come so many teams fall short of their sprint commitment? Why is it so hard to close stories?

I could talk to you about risk and uncertainty. I can also advise you on how to reduce risk, but you probably already know the drill. That’s why you already reduce your risk by practicing scrum and time boxing your commitment into a 2-4 week sprint. Good start.

What I am going to talk about is a change of focus.

These 3 changes can dramatically improve your team’s ability to close stories:

  1. Focus on closing stories not completing tasks
  2. Take advantage of the benefit of small batches
  3. Try pair programming

1. Focus on Closing Stories not Completing Tasks

Most teams setup a manual or automated sprint story board to track sprint progress. A typical manual story board is illustrated below:

Manual Story Board

At the start of the sprint, the Product Owner prioritizes the stories along the left side of the story board and the Development Team identifies the tasks required to complete each story.  At daily standup, the Development Team reports progress on the stories and tasks.

A common practice at standup is for team members to report on the status of their assigned tasks in a round-robin manner. This traditional task focus often causes the team to lose sight of the real goal: quickly closing the story.

The key is to change your focus from task to story. At standup, try going round-robin by open story, starting with the highest priority story at the top of the story board. When the team changes focus to the overall status of the story instead of the individual tasks, the entire team has visibility and input to completing it.

2. Take Advantage of the Benefit of Small Batches

Lean manufacturers like Toyota discovered that small batches made their factories more efficient. It seems counter-intuitive that starting and completing one story at a time from start to finish is actually more efficient than every developer on the team opening their own story at the start of the sprint.

The practice of opening fewer stories works because there is less work in progress (WIP). Combine that with the synergy of multiple developers working to complete each story and your team begins closing more stories and improves its burndown.

This concept goes hand-in-hand with the team’s new focus of closing stories.

3. Try Pair Programming

When the team decides to open fewer stories, how do multiple developers constructively work together? In the spirit of self-managing teams, I suggest the Development Team research and learn about pair programming techniques and determine the best way to apply them.

The benefit of pair programming is higher quality code and shared knowledge. The formal definition of pair programming has 2 developers work together at the same workstation, with one developer programming or driving and the other developer navigating or focusing on overall design. The developers can switch roles.

I’m not suggesting that your developers share a single workstation, but I am suggesting that 2 developers can work together, share the work required to complete a story and close the story more quickly.

How many times has work stalled because the developer has questions about requirements? If 2 developers shared the story, one developer could meet with the Product Owner while the other developer starts writing automated tests and begins high-level design.

This is just one example. There are many creative ways we can work together and get more stuff done.

We’re agile.

We’re experimenting.

We’re getting more efficient.

What are some techniques your team uses to increase velocity?
I’d love for you to share in the Comments.

Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

Contact Us read more