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.

Did You Know GSD Scrum in 1 Day Workshop has gone Virtual?

GSD Mindset now partners with Amananet to provide our popular GSD Scrum in 1 Day Workshop online. We’re not talking about a recorded session. We’re talking about receiving the same training that you’d expect from one of our live workshops without leaving your home or office. Always wanted to attend our workshop, but don’t live near Portland? Now you can! Register and join us on December 7, 2017.

Register Now

 

Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more

Scrum of Scrums Manages Cross-Team Commitments

Scrum of Scrums Facilitates Coordination across Teams

Agile Scrum teams are generally organized around projects or core capabilities, where teams support a set of products that serve a common business purpose. When Scrum teams are organized around core capabilities, project initiatives often require deliverables from multiple capabilities. Even Scrum teams specifically organized to deliver a single project can find themselves in need of functionality built by another Scrum team.

Almost every Scrum team in a company large enough to form multiple Scrum teams has cross-team requirements, but very few companies take advantage of Scrum of Scrums. With a strong commitment to the spirit of cooperation and a little organization, cross-team product or project deliverables can easily be managed through the Scrum of Scrums concept.

The Scrum Alliance and Agile Alliance both talk about the Scrum of Scrums technique, but they recommend holding this coordination meeting every day. We think that’s overkill. We think holding a well-organized Scrum of Scrums every other week is good enough. For those who practice two-week sprints, hold the meeting on the off week from Sprint Planning.

Start with a Plan

Every Scrum Team needs to plan. If your Scrum team is not release planning or identifying quarterly deliverable goals, then start today. Before you jump up and down and tell me you can’t plan because you’re agile, cool your jets. I’m not saying you need a 500 line Microsoft Project Plan; I’m saying you need deliverable milestones by Epic. Why? So, you can identify when you need product deliverables completed to stay on schedule.

If you don’t know how to plan for Agile, read Chapter 2 of the GSD Scrum Handbook: GSD Gold Project Planning.

Once you know what you need and when you need it, then you can approach your sister Scrum teams and negotiate delivery dates.

Meet Regularly to Stay on Schedule

Once you have delivery commitments, ensure all Scrum teams stay on schedule by meeting once each Sprint. Remember that not all Scrum teams are on the same Sprint cadence, so be specific about due dates. Give your sister Scrum teams plenty of lead time to get your needs on their Backlog.

Use the Scrum of Scrums meeting time to ensure the right Stories get brought into the right Sprints.

Who runs the Scrum of Scrums?

Depending on the formality of company processes, the scope of the project and the Scrum team structure, the Scrum of Scrums can be chaired by any one of many job titles. With more formal team structures, these meetings may be led by the Program Manager or Project Manager or Product Manager. With less formal teams, the Scrum Master who needs the external deliverables may take the lead.

What Happens at the Scrum of Scrums?

Keep the Scrum of Scrums to a half hour meeting.

Focus only on cross-functional deliverable dependencies:

  1. Start the meeting with a brief review the upcoming quarterly or release milestones.
  2. Verify that the Stories identified for completion in the previous Sprint were completed.
  3. Identify Stories for completion in next Sprint. Obtain commitment from sister Scrum Teams.

What the meeting IS: a meeting about dependencies, shared milestones and issues.
What the meeting IS NOT: a giant Standup or project status meeting.

When your project or product requires cross-team coordination, taking advantage of Scrum of Scrums can keep everyone focused on the right work at the right time.

I’d love to hear about your successful use of the process.

Did You Know GSD Scrum in 1 Day Workshop has gone Virtual?

GSD Mindset now partners with Amananet to provide our popular GSD Scrum in 1 Day Workshop online. We’re not talking about a recorded session. We’re talking about receiving the same training that you’d expect from one of our live workshops without leaving your home or office. Always wanted to attend our workshop, but don’t live near Portland? Now you can! Register and join us on December 7, 2017.

Register Now

 

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

Whaaaaat?!

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

Why Every Story should have Acceptance Criteria

Better Understand the Purpose of Story and Acceptance Criteria

Some who practice scrum believe that acceptance criteria are optional. Others only write a one sentence summary and don’t even bother writing story requirements. These practices could be a recipe for disaster, because developers may not understand what to develop and testers may not know what to test.

At GSD Mindset, we teach that acceptance criteria are mandatory, and we spend lots of time helping those new to scrum learn how to write stories. The story describes the requirement for that next slice of functionality the team needs to build. The acceptance criteria describe how the product owner and team know that the functionality works; they also describe what happens when something goes wrong.

If story content so profoundly impacts the team’s ability to produce quality work, then why do so many teams write crappy stories? We get that it takes time to think through and document the specific functional requirement, plus also to think through how to tell that the function works. We get it that most teams write their stories the night before or the morning of Story Grooming. We get it: your team is busy.

How much busier does the team become when stories take too long to close? How much busier does the team become after they build the wrong functionality and they have to rewrite it? How much busier does the team become when the project gets behind schedule?

After high level design and Epic breakdown, writing good stories is one of the most important activities the team performs. Taking the time to write a clear, concise story with clear, concise acceptance criteria can be one of the most important predictors of green project status and excellent quality.

How Do You Write a Good Story?

The Story format is simple:

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

When you sit down to write a story, think about who will be using the functionality, even if the user is another automated process. From the user perspective, visualize what function the user will be performing and why this slice of functionality is important.

For example, think about the customer of a shopping website. If the requirement is to build the first slice of a search tool, think about how the customer wants to search. Suppose research shows that most customers are brand conscious. Then write the first slice to search by brand:

As a customer of this shopping site,
I want to enter my favorite brand name
So I can see easily see all the products available for sale and quickly browse the list.

The requirement for this slice of functionality is clear. The reader understands what the customer wants to do and why: Because they came to the website with a specific brand in mind.

Yes, there are other ways customers search: by price or clothing type or gender, etc. But agile scrum stories only describe a slice of functionality. Every one of those other search parameters should be described in separate stories.

The acceptance criteria format is simple too:

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

How does the tester know that the brand search is working?

Given that the customer enters a brand name,
When the customer clicks to search,
Then the website returns the list of clothing in stock for that brand and displays a list that includes: small image, product name and price.

What does the website do if there is no clothing in stock for the brand?

Given that the customer enters a brand name,
When the customer clicks to search,
If there is nothing in stock for the brand, the website returns a message that includes the search parameter and offers the customer options to search for similar brands (e.g., people who search for A also search for B).

The effort to write a complete story that clearly describes required functionality and what to look for when testing does not really take much more time than writing a crappy, incomplete story. If your team is not writing stories complete with acceptance criteria, I urge you to try writing complete stories for at least 3 sprints.

I’ll bet you love the results!

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

read more