Overview

I love helping teams deliver more application and cloud platform features faster to happier customers. An important component of being able to accomplish this is following an Agile methodology that works.

In this post I will cover how teams can get the most out of Agile principles and practices to deliver products faster and more iteratively. The concepts in this article heavily leverage the Scrum and Scaled Agile (“SAFe”) frameworks and are based on my experience delivering large scale development efforts.

Agile Roles

Having a clear understanding of roles and responsibilities within an Agile team are critical to success. There are four primary roles to consider when determining who should be involved in Agile ceremonies. These are the Product Owner, Scrum Master, Scrum Team and Stakeholders.

Product Owner

A Product Owner is the single person who is responsible for the success of a Product and for maximizing the value of that Product.

Responsibilities

• Setting the vision and representing the interests for all stakeholders on the team (e.g. Business Owners, End Users, Domain Experts, etc.)
• Defining and altering scope of efforts or Features to be delivered in a Sprint(s)
• Maximizing the value and success of a Product and its ability to provide ROI
• Reporting on progress and problems to stakeholders
• Accepting the final product at the conclusion of a Sprint or project

Scrum Master

A Scrum Master is the facilitator for an Agile development team who manages the process for how information is exchanged.

Responsibilities

• Facilitating and enforcing the teams Agile rituals and processes
• Removing roadblocks from the teams path
• Committing goals and timelines on the teams behalf

Scrum Team

The Scrum Team is a multi-disciplinary team responsible for the creation and delivery of a system. This includes modeling, programming, testing, and release activities, as well as others.

Responsibilities

• Assisting the Scrum Master with prioritizing items from the product Backlog and assigning effort in Sprint Planning meetings
• Self-organizing using the teams Backlogs and Sprint boards
• Working on activities that help to accomplish Sprint goals and deliver products within designated sprint cycles

Stakeholders

Stakeholders are individuals with a vested interest in the success of a project that aren’t directly involved in building a product but may participate in the development process in various ways.

Responsibilities

• Sharing details or answering questions that might inform product development
• Conveying priorities, desired outcomes and concerns to the Product Owner
• Understanding progress, problems and changes to the plan communicated by Product Owners

Agile Meeting Framework

A framework is a structure that serves as a foundation so you’re not starting entirely from scratch. The Agile meeting framework describes the ceremonies (also knowns as rituals) and timelines for how an Agile process can be run as part of the product delivery lifecycle.

The most important ceremonies for any Agile process are:

1. Backlog Grooming
2. Sprint Planning
3. Daily Scrum
4. Sprint Review
5. Sprint Retrospective

The diagram below shows how these meets are used to create a continuous, iterative process for solution development.

Sprints are typically two-weeks in length. Based on my experience, one-week Sprints are generally too short to deliver significant end user value with more administrative overhead and three-week Sprints are too long to consistently and accurately estimate.

During any given two-week Sprint cycle, teams work toward a stated goal to deliver a product Feature based on a planned Backlog. The focus should be on rigorous grooming and planning so that the team can work as autonomously as possible and spend the majority of their time executing against work assigned to them.

The diagram below shows a typical two-week Agile Sprint cadence that starts on a Monday and ends on a Friday with N representing the current Sprint and N – 1 or N + 1 representing previous and future Sprints.

Agile Meetings

Each Agile ceremony has a very specific purpose. This is intentional to keep teams focused on product delivery. An important concept to understand is that none of the Agile ceremonies are intended as a forum to solve problems. They are meant to address a specific activity that needs to happen to effectively plan and deliver new features. The following sections outline the most important Agile ceremonies and what they are used for.

Backlog Grooming

Backlog Grooming is used to review items on the backlog to ensure that it contains the appropriate items that are prioritized as per the latest delivery schedule. All members of the Agile team attend this meeting once every two weeks prior to Sprint Planning for every 5 Agile Team members. Stakeholders are optional.

Benefits

• Provides the team with a prioritized and clarified Backlog of Features to be delivered
• Sets the stage for effective Sprint Planning
• Reduces rework in development and testing
• Helps to identify risks and dependencies early

Checklist

• Review and groom backlog prior to meeting (ongoing)
• Review all Features top to bottom and determine relative priority
• Add or clarify descriptions as required so team understands Features to be delivered
• Create new and remove existing Features as required
• Spilt Features that are too large
• Review User Stories within Features and identify gaps
• Provide high-level Story Point estimates for User Stories in highest priority Features
• Determine if User Stories need to be split
• Add definitions and acceptance criteria to User Stories

Sprint Planning

Sprint Planning is used to create a shared sprint goal, determine product backlog items that the team will work on to achieve sprint goals and discuss their initial plan for completing those product backlog items. The Product Owner, Scrum Master and Scrum team attend this meeting once every two weeks prior to the start of each Sprint for one to two hours.

Benefits

• Enables the team to agree on the sprint goal and commitment
• Creates the platform to communicate dependencies and identify team capacity to set and commit to an achievable sprint goal
• Ensures that daily Sprints remain productive

Checklist

• Remind the team of the big picture or goal
• Discuss any new information that may impact the plan
• Present the velocity to be used for the Sprint
• Confirm team capacity
• Confirm any currently known issues and concerns and record as appropriate
• Review the definition of done and make any appropriate updates based on technology, skill, or team member changes since the last sprint
• Present proposed product backlog items to consider for the sprint backlog
• Determine the needs, sign up for work, and estimate the work owned
• Product Owner answers clarifying questions and elaborates acceptance criteria
• Confirm any new issues and concerns raised during meeting and record
• Confirm any assumptions or dependencies discovered during planning and record
• Scrum Master calls for a group consensus on the plan
• Team and Product Owner signal if this is the best plan they can make given what they know right now

Daily Scrum

Daily Scrum is used to find out the results of the previous day’s work, to get each team member to plan their day, and to give everyone the chance to get help with anything they’re stuck on. The Scrum Master and Scrum Team attend this meeting each day for 15 to 30 minutes with the Product Owner as optional.

In general, 15 minutes should be enough for each increment of 5 team members. Teams larger than 10 should be looked at for opportunities to determine if they should really be working as part of two delivery streams to maximize focus and effectiveness of Agile teams.

Benefits

• Enables the team to be in sync on how things are going
• Allows for identification and solution of impediments
• Provides an opportunity for small course corrections within the Sprint
• Builds trust between team members
• Improves visibility of progress
• Promotes self-organization in team: team members hold each other accountable for achieving their daily commitments

Checklist

• Take note of attendance
• Ask each member of the team:
  • What did you complete yesterday?
    • Ask for related task or bug
    • Drive completed point home
  • What are you doing today?
    • Ask for related task or bug
  • Are there any roadblocks in your way?
    • Ask for related task or bug
• Share progress and determine if anything is required to meet the sprint goal

Sprint Review

Sprint Review, also known as Iteration Review, is used to compare the original Sprint goal to the outcome of the Sprint. A Sprint is generally considered successful if the goal was met even if all tasks were not completed. All members of the Agile team attend this meeting once every two weeks at the end of each Sprint for one hour for each 5 Agile Team members. Stakeholders are optional.

Benefits

• Promotes early and frequent feedback from stakeholders
• Builds team and collaboration
• Maximizes quality
• Enables formal acceptance of work

Checklist

• Determine what team members will be presenting demos, if applicable (before meeting)
• Review the work that was and was not completed in the sprint and tie success back to the sprint goal
• Provide a demo of completed Features from the end-user perspective
• Review key decisions and why they were made
• Refer back to product roadmap or completion status of epics

Sprint Retrospective

Sprint Retrospective is used to discuss the just-concluded Sprint and determine any changes to improve the next sprint. The Scrum Master and Scrum Team attend this meeting every two weeks at the end of each Sprint for one hour with the Product Owner as optional.

Benefits

• Allows for the collective identification of ways to improve productivity and reach goals
• Reinforces the definition of done
• Helps the team continuously improve and evolve
• Builds the team’s sense of ownership and its self-management
• Promotes openness

Checklist

• Share thoughts and ideas to make future sprint cycles more productive
• Document things that went well during the sprint cycle
• Document things that could have gone better during the sprint cycle
• Add identified suggestions for improvement to the backlog to be prioritized and worked

Agile Artifacts

Artifacts are “information radiators” and they serve to capture the shared understanding of the team at a particular point in time. Artifacts play a vital role for the team to reflect themselves on how they are doing with the Sprint goal. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.

Example Artifacts

• Product Backlog – The Product Backlog is a set of all baseline requirements prioritized in order which is made available by the Product Owner to the Scrum Team. It emerges and evolves over time and the Product Owner is responsible for its content and validity.
• Sprint Backlog – The Sprint Backlog is a subset of the Product Backlog that the team pulls into the Sprint to work on. It is the list of “To Do’s” a team might be working during the current sprint. The work items in the Sprint Backlog are broken down further into tasks by the team. All items on the Sprint Backlog should be developed, tested, documented, and integrated to fulfill the sprint commitment.
• Product Increment – The most important Scrum artifact is the Product Increment. Each Sprint the development team produces potentially shippable product increment (PSPI). This product increment must align to the development team’s “Definition of Done” and this increment must be acceptable by the Product Owner.
• Program Increment – The Program Increment (PI) is part of the Scaled Agile Framework. It is a time-box during which incremental business value is delivered over several Sprints. PIs are typically 8 to 12 weeks long. The most common pattern for a PI is four development iterations (Sprints).

Story Point Estimation

Story points provide a high-level effort estimation for User Stories. Consistent estimation of story points over time helps to establish a stable velocity for a team that can be used to plan and rationalize work assigned for Sprint delivery.

There are many different approaches to Agile story point estimation. Here are some things that I have found work well:

• Use Scrum Poker to make sure the team is aligned on the overall points assigned to a User Story. This helps the team see where two or more people might have a misalignment on points and can help drive discussions about the nuances of why there is a difference.
• Use the Fibonacci sequence method to pointing. This means that all User Stories are assigned either 1, 2, 3, 5, 8, or 13 points. This is helpful because humans are notoriously terrible at estimating the bigger something gets. Using this approach helps to account for uncertainty which an impact delivery.
• Round story points up when you exceed a threshold. In other words, if you are deciding between a 3 and a 5 go with a 5. Inaccurately accounting for uncertainty almost always leads to incomplete Sprints or cut corners on delivery.
• This will be the most controversial recommendation, but tie your story Points to business days or hours. This helps to give a concrete meaning to story size and enables better planning in hybrid organizations that use Waterfall and Agile approaches. At the end of the day, we are trying to measure effort and at some point a certain level of effort is going to align with an amount of time required to complete a story. Points should ideally be based on the person delivering the work as well. Someone who is new to something might be at a 3 where a seasoned professional might be able to do the same work with a 1.

Story Points Matrix

With all of that said, here is my approach to story point estimation.

All User Stories should fall within a single Sprint. Any User Stories larger than this should be broken down into smaller, deliverable components that have intrinsic business or strategic value. Based on this definition, the ranges in the table below are determined based on the overall consumption of a two-week Sprint that a User Story would consume.

–	XS	S	M	L	XL	XXL
Approximate Size (Business Days)	Less than 1	1 to 2	2 to 3	3 to 5	5 to 8	8 or more
Story Points To Be Used	1	2	3	5	8	13
Approximate Number That Can Be Completed by 1 FTE	12	8	4	2	1	<1
Actions	Compose		<	–	>	Decompose

Over several Sprints, the team will develop a velocity based on the consistent application of Story Points to User Stories. Once established, the teams Velocity can be used to help understand the amount of work the team can accomplish in a Sprint and inform discussions about priority.

Experience Based Considerations

The following section outlines my point of view on several topics that often come up as part of the Agile discussion.

Who enters work items?

This can be different for different teams. Product Owners might be more involved at the Feature level where Scrum Masters will work with Scrum Teams to create the User Stories to deliver a Feature. Because one of the benefits of Agile is to help Engineers and Developers to work more autonomously, I have seen it work well when the person who owns a User Story (a member of the Scrum Team) adds their own tasks. This helps to ensure they fully understand the acceptance criteria and enables them to self-manage their work. As a general rule, I try to ask team members to add at least one Task per story point so that progress can be demonstrated at a more granular level.

Who updates work items?

The resource representing the requestor or Product Owner should provide clarity on scope and acceptance criteria so that the Scrum Master can effectively ensure the work is properly prioritized, documented and delivered.

The resource assigned to the work item should be entering child work items (e.g. Tasks if the request is represented at the User Story level, User Stories if the request is represented at a Feature level), updating status, and adding any completion notes.

Who participates in the process?

Everyone who is part of the delivery of a Product or project as defined by the above Agile ceremonies.

When will the work item be complete?

All work should always be completed within the boundaries of the Sprint or Iteration. There should not be a constituted concept of “carryover work”. While there will be cases where work might need to be moved to another Sprint, it is important not to become “okay” with the concept that carryover work is a standard part of any Sprint. This matters because when Business Stakeholders and Product Owners lose faith in the ability of the team to effectively plan and deliver work using an Agile approach they tend to fall back to more waterfall based approaches.

When will the Product be complete?

In general, while milestones or releases might be achieved, by its definition a Product will always be in progress. The initial effort to stand up a new Product will be determined by the size of the Backlog and velocity of the team. Getting transparency into this takes careful planning and a through understanding of requirements.

Who reviews the work?

All members of an Agile team other than Stakeholders are responsible for some level of review. In general, work should be accepted at the end of a Sprint by the Product Owner. During development, it is important for the team to be engaged in peer review of documentation and code to ensure the highest quality possible delivery. The owner of a given User Story is responsible for reviewing the completed work to make sure it is well documented and meets the letter and spirit of the acceptance criteria.

Can I add new User Stories into the current Sprint?

As a general rule, User Stories should not be added to, or removed from a Sprint once it has started. New User Stories should be added to the backlog for prioritization and planning for the next Sprint. If a team member completes all User Stories assigned to them ahead of time, we should prioritize helping the rest of the team deliver their User Stories over scoping more work. Adding User Stories in the middle of a Sprint may cause us to lose focus of our shared Sprint goals and makes the assumption that all other team members will finish their work-in-progress by the end of the sprint and that we will be able to complete the new User Story by the end of the Sprint. Taking this approach will also hopefully help us to better assess our velocity and improve our planning.

Valid reasons for adding or removing User Stories might be an urgent change in priorities, unplanned leave, or other similar unplanned events. In any case, nothing should be scoped in or out of a Sprint without a discussion with the Scrum Master and Product Owner to make sure it is appropriate.

What meeting is used to solve our problems?

None of the Agile rituals should be used to figure out how to solve a problem. See below for the core questions that each ritual answers:

• Backlog Grooming – How do we plan it?
• Sprint Planning – How do we execute it?
• Daily Scrum – How do we make work transparent?
• Sprint Review – How to we measure our success?
• Sprint Retro – How do we do better?

None of this is “how do we solve the problem?” If a team member needs help with work or solving a problem, a meeting with the necessary individuals should be scheduled outside of the Agile rituals.

What do I do with work items that are not completed in a Sprint?

As previously noted, there is no such thing as carryover work. What this means is that we should always aim to only scope work into a Sprint that can be completed within that timeframe. Here are some strategies that might help:

• Focus on clearly defining User Story descriptions and acceptance criteria in Backlog Grooming
• Break User Stories that can’t be completed within one week down into smaller Stories
• Use Sprint Planning to get teams to commit to work and hold them accountable throughout the Sprint
• Break User Stories down into units of less than one day using Tasks to improve transparency and the ability to point to daily completed work
• Use Sprint Review to confirm acceptance criteria was fully met by performing demos
• Use Sprint Retrospective to determine how to investigate what could be done better next time

With that said, there will be times that not all work is completed in a Sprint. Any work not completed in a Sprint should be moved to the backlog at the beginning of Sprint Planning in the following Sprint and prioritized against all available work to ensure it is still the most important and urgent thing to complete in the Sprint. Work items that are not completed as part of the Sprint should not be moved out of a Sprint until Sprint Planning to ensure accuracy in our reporting processes.

In Conclusion

Leveraging a modern Agile approach can help teams deliver more features faster to happier customers in a way that is more collaborative, iterative and focused on Product development.

In order to get the most out of Agile, teams should be rigorous about implementing Agile as fully as possible and continuously improve as the team matures from a process and cultural perspective.

Finally, focusing on what matters most, scoping work appropriately into Sprints and following a consistent approach to Sprint delivery and User Story estimation can help improve predicability of Sprint delivery driving organization trust and adoption.

Thanks for reading my post.