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

Project Planning Without Knowing the Details

Agile Project Planning Techniques Overcome Fear of Unknown

We understand there is an overarching desire in project management to know a good amount of detail before project planning takes place. Traditionally, these details are constrained by Time, Scope, and Budget.  It has almost always been my experience that Time and Budget that are fixed.

If two of our three biggest constraints are fixed, then why are we so afraid of project planning? We fear the unknown. This fear of the unknown can range from intimidating to downright scary. The GSD Method of agile scrum offers several techniques to overcoming this fear that keeps us becoming better project planners and accurately predicting what and when we are going to deliver results.

Change the Fundamental Way You Plan Projects

In traditional waterfall project management, we typically get a six month to two year roadmap, and we build out a detailed work breakdown structure with hundreds to thousands of tasks (no joke, I have actually seen a project with 10,000 tasks to plan and track). Then, we go through weeks of scheduling those tasks with the core and extended project team, only to find that about two months into the project, the plan is irrelevant and out of date.

The first step to throw out the notion of traditional waterfall planning and begin thinking in terms of Epics instead of work breakdown structure. What is an Epic you ask?

Think in Terms of Epics

An Epic is a high level feature of a product or application. For purposes of this post, let’s say we want to develop an airline reservations application.

At the start of the project, the Scrum Master brings the Development Team together with the Product  Owner. The Product Owner lists the features (or groups of related functionality) that the customer needs the team to deliver to meet business deadlines. Each feature becomes an Epic.

A few example Epics of our airline reservations project include:

  • Customer Login
  • Customer Book Airline Reservation
  • Customer Search Airline Reservation
  • Customer Change Airline Reservation

Decompose the Epics into Components

Once the team identifies the list of Epics to be delivered as part of our project, it is time to break these Epics down into GSD Gold Components. A GSD Gold Component is a unique part of the feature set that can be delivered as standalone, independent functionality. For our object-oriented or UML friends, think of a GSD component as a use case.

We could decompose our Back to our Customer Book Airline Reservation Epic into the following Components:

  • Customer searches for available airline flights
  • Customer selects flights to book and creates an airline reservation
  • Customer pays for airline reservation
  • Customer searches previously booked reservations

When the team cannot think of any new Components for all Epics in the project, it is time to start thinking about the MVP (Minimal Viable Product) and scheduling release milestones.  

Define the MVP and Delivery Roadmap

The Product Owner and the Business Analyst (if you are lucky enough to have one on your scrum team) meet with your customers and identify the highest priority components that provide the most value and should be delivered first. If the team has 90 days to deliver a fully functioning airline reservations application, a full review of all the Epics and related decomposed Components should be reviewed and prioritized.

The following steps help identify the MVP:

  1. Group Components that should be delivered together (these definitely can reach across Epic feature sets)
  2. Prioritize Component groups for delivery and decide release dates
  3. Rework the Component groups until the team feels comfortable delivering by the release dates assigned to the team

Viola! We now have an agile release plan that, in the real  world, lines up against strategic roadmaps and that the team feels comfortable delivering.

Focus on Near-Term Deliverables

Agile is not an excuse for cowboy coding. Once you know the Epic features your team plans to deliver, have your architect or tech lead create a high level design or architecture roadmap for your application.

Now, it is time to start focusing on near-term deliverables. We’re not talking about breaking down every Component into a detailed plan, we’re talking about focusing on what we need to accomplish in the next 2-4 weeks or the next two 2-week Sprints. A Sprint is a time-boxed development cycle. Our Sprint preference is 2 weeks, as we believe this is optimum for most development teams.

To get ready for the team’s first Sprint, the Product Owner and Business Analyst further break down the highest priority Components into Stories. In agile scrum, Stories are the requirements and quality assurance acceptance criteria that make up what need be delivered.

You don’t have to write every Story for every Component, only those Stories that must be delivered in the next 2-4 weeks. How awesome is it that? The first two sprints set the pace or velocity of the project, give the team something to demo so the customer can validate their requirements, allow the team time to pivot if requirements change and ensure the team has the confidence to deliver on schedule.

For more information, check out:

Chapter 2 in our GSD Scrum Handbook: GSD Gold Project Planning 

Chapter 3 in our GSD Scrum Handbook: GSD Gold Story Writing

Happy planning,

April Shepherd

April Shepherd
AprilS@gsd.guru  503.307.9072

Contact Us read more

Maximize Velocity in Two Week Sprint

Preferred Two Week Scrum Sprint Schedule

When teams are new to agile scrum, they find it difficult to organize their work to best meet their Story Point commitment in a two week sprint. I’m all about organizing for success, so I decided to share my personal best practice Sprint Schedule.

Daily Standup is Best Held in Morning

A best practice is to hold the Daily Standup in the morning. That way, everyone on the team presents their status, next steps and blockers at the beginning of the work day. Issues are raised and plans of action are devised with the entire day available to execute corrective action. Team members who floundered yesterday, can get the help they need from their teammates early in the day and get their Stories back on track. The Scrum Master has all day to remove any new roadblocks.

Week One – Focus on Burn Down

The goal for the first week is to close the highest priority Stories. Starting the Sprint with a healthy Burndown (refer to my earlier post on Burndown Charts) keeps the team from going off a cliff at the end of the Sprint, rushing to close their Stories at the last minute.

While the Development Team is closing Stories, the Product Owner and Business Analyst should meet with the customer to demo the features completed in the prior Sprint. This gives the customer a chance to provide feedback on recently completed features, and gives the Product Owner assurances that the completed features meet the customer’s needs.

Depending on the feedback, the Product Owner may need the Development Team to pivot slightly or make a few changes in the next Sprint. By demonstrating for the customer early and often, the customer can better envision the completed product. Any requested changes should be small, so the project can remain on schedule.

After receiving feedback, the Product Owner can re-prioritize the Backlog and work with the Business Analyst to write missing high-priority Stories needed for next Sprint.

Major changes or new functionality requests by the customer should go through change control for approval. Even though the team is agile, they are still working on a budget and must deliver according to their release schedule.

A typical Week One schedule looks like:

  • Day 1 Mon – Sprint Planning
  • Day 2 Tue – Customer Demo and Feedback on last Sprint’s Stories
  • Day 3 through Day 5 (Wed through Fri) – Close Stories and Build Backlog

Week Two – Prep for Next Sprint

The goal for the second week is to continue closing Stories and prep for next Sprint Planning. At Standup on Monday of the second week, take a hard look at the Burndown Chart and Sprint Backlog. Has the team closed 50% of its Stories? If not, quickly assess root causes and work with the team to make a plan for corrective action. Remember, life is not linear. There is still time to meet all Sprint commitments.

The beginning of the week is also time for the Product Owner to review all the new Stories written last week and reprioritize them against the existing Backlog. Tuesday is a good day to reprioritize the Backlog and identify the highest priority Stories for grooming and estimating. Don’t let the Product Owner wait and perform this task during the Story Grooming meeting.

Mid-week is the best time to groom and estimate Stories. Insights gained during Story grooming and sizing provide the Product Owner with additional knowledge with which to reassess the Backlog one last time before Sprint Planning.

Conduct the Retrospective and Team Demo on the last day of the Sprint. Celebrate wins. We recommend providing refreshments and snacks. This puts everyone on the team in a good frame of mind to discuss process improvements.

A typical Week Two schedule looks like:

  • Day 6 Mon – Assess Sprint Status
  • Day 7 Tue – Continue to close Stories and Prioritize Backlog for Grooming
  • Day 8 Wed – Story Grooming and Story Point Estimating
  • Day 9 Thu – Re-prioritize Backlog
  • Day 10 Fri – Team Demo and Retrospective

Alternative to Team Demo during Retrospective

To minimize meeting length on Retrospective day, several teams I’ve worked with have opted to include Team Demo as part of their Definition of Done (DoD). This means team members working on a Story must Demo it after Quality Assurance (QA) tested in order for the Story to be eligible for closure.

To keep the post short, I only discuss the scheduling of Sprint activities and not their definition or best practices. For those readers new to agile scrum, I recommend you read our GSD Scrum Handbook. It’s talks about the GSD Scrum Method for practicing agile scrum in more detail.

Focus and coordination of small sets of activities is the key to organizing and managing a successful sprint.

Let me know if there is anything else I can help you with,

Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

Contact Us read more

The Difference Between Scrum Master and Project Manager

Scrum Master Role of Servant Leader is Methodology and Mindset Shift

Many new to agile find it difficult to distinguish between a scrum master and traditional project manager. I’ve worked in both roles, and I can tell you that the two roles are quite different. The scrum master is more a servant leader, while the traditional project manager is more a task master. The project management techniques and approach are also quite different too.

Traditional Project Planning Focuses on Tasks

After drawing boundaries around project scope, the next step in traditional project management is to gather requirements and break down all the development activities that must be executed to meet those requirements into a hierarchical work breakdown structure (WBS). Tasks are defined to complete WBS activities and members of the project team provide estimates to complete each one. The team also identifies project dependencies between tasks. The traditional project manager enters all this information into a Microsoft Project Plan.

The traditional project manager assigns the tasks in the plan to team members, who work on them according to plan. The project manager tracks progress against the plan and closes tasks as they complete. When all tasks are completed, the finished application is user acceptance tested and delivered to the customer in production.

Sound familiar? Yes. Do projects always execute according to plan? No.

What happens when they don’t go according to plan? Risks management plans get executed, Issues and Action Items get raised and resolved, and Change Control attempts to rewrite requirements mid-project. The original project plan becomes meaningless. Much butt covering ensues.

Agile Project Planning Focuses on Completed Features

In agile scrum, after defining project scope, the next step is to break down the application into pieces of working functionality that meet customer requirements. The scrum master works with the team to identify what working functionality provides the highest value to the customer. These most valuable features delivered in a completed application are often referred to as the Minimum Viable Product (MVP) or Minimum Marketable Feature (MMF) set.

The team focuses on the MVP functionality first. They write detailed requirements or stories that describe the MVP functionality. The team schedules them for development, demo and release as soon as possible. The rest of the functional components are prioritized and organized into a release schedule.

See the difference in focus? Traditional project teams focus on tasks in the project plan, and agile teams focus on delivering features in the MVP. Traditional project managers focus the team on organizing and completing tasks, and the agile scrum master focuses the team on prioritizing and releasing the customer’s highest priority features as soon as possible.

When the team delivers valuable functionality to the customer early and often, the customer can provide feedback on completed features earlier too. If the customer is not satisfied, functional requirements can change and the team can pivot. The team has a better chance to meet its project deadlines than it does on a traditionally managed project.

Responsibility Shifts to the Development Team

The Greenleaf Center for Servant Leadership best describes the servant leader role of the scrum master: “The difference manifests itself in the care taken by the servant-first to make sure that other people’s highest priority needs are being served.” When applied to agile, the “other people” include not only the customer but the project team too. The scrum master is responsible for ensuring the needs of both the customer and the project team are met.

This starkly contrasts with the traditional project management role. Although traditional project managers do not complete the work, the role assigns them primary responsibility for completing the project on schedule. The project manager’s responsibility to create a plan, report status, assign tasks and issues and action items often creates contention with team members if the project gets behind schedule.

Agile is all about self-managing teams. So in agile scrum, much of this responsibility shifts to the development team.

During an agile scrum project, it is the development team’s responsibility to:

  • Accept stories (detailed requirements and test criteria) as properly groomed, well-understood and correctly sized.
  • Decide how many stories to bring into a sprint (or time-boxed development cycle).
  • Complete all the stories brought into the sprint.

The scrum master’s responsibility shifts to adhering to the rules of agile scrum and removing roadblocks, so the development team can meet their sprint commitments.

Even if you do not understand anything about agile scrum or how to organize and manage an agile scrum project, you can clearly see the drastic difference between the 2 roles. As a traditional project manager, if you have transitioned to agile scrum and you continue to practice task management, you are not a scrum master. The transition from traditional project manager to scrum master is as much a mindset shift as it is a methodology shift.

If you have any questions about becoming a scrum master, reach out and contact us.

Cynthia Kahn

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500

Contact Us read more