Parijat Dutta

As per a 2023 survey by State of Agile: 37% said business teams simply don’t understand what Agile is or what it can do, while 27% said there is not enough training.

As Agile methodologies continue to mould today’s fast-paced digital landscape, organizations still struggle with Agile implementation. According to a 2023 State of Agile Report, while over 95% of organizations have adopted Agile practices, yet 47% of Agile projects fail due to improper setup and execution.

In my 10+ years of coaching, building and leading agile teams, I have noticed a tendency to draw parallels to the waterfall world. While the practice may make it easier for individuals to come to terms with the new methodology where Business Analysts become Product Owners, and Project Managers become Scrum Masters, it’s not essentially apples to apples. At best it muddies the responsibilities of each key contributor, and at worst it creates large gaps that lead to unavoidable failure.

The same extend to the way work is sized and projected, and the manner in deciding whether or not a final product meets end-user expectations.

In this article I would draw from my experience to answer 3 key questions asked by every team struggling to embrace agile practices:

1. How do Product Owners, Tech Leads, and Scrum Masters contribute to Agile ceremonies?
2. How do we define “done”?
3. How should we size stories?

Whether you are new to Agile or looking to refine your existing practices, these best practices will help you and your team navigate common pitfalls and achieve Agile success.

1. How do Product Owners, Tech Leads, and Scrum Masters contribute to Agile ceremonies?

While Agile framework encourages each team to shape their own team-structure to some extent, I find it works best when there is a skeleton to start with. I rely on the following tenets when building a new Agile team.

	Product Owner/Manager	Scrum Master	Technical Lead / Architect
Who am I?	Voice of the customer / business / client	Voice of the scrum team	Voice of the solution
How do I contribute during PI Planning?	1. Present last PI’s accomplishments to stakeholders 2. Work with customers / clients to understand needs, priorities, success criteria. Document them into features. 3. Work with Tech Lead / Architect to identify necessary spikes. Develop features for the spikes. 4. Break all features down to user stories. 5. Work with Tech Lead / Architect to size stories. 6. Work with Scrum Master to pull stories into sprints. 7. Present PI outlook to stakeholders.	1. Present team metrics, key challenges, lessons learnt from last PI to stakeholders 2. Work with Release Train Engineer to address issues that the team is facing (capacity / infrastructure / training etc.) 3. Work with Product Owner to pull stories into sprints based on team velocity, capacity, and priority. 4. Present next PI projections from team metrics perspective (velocity, burndown, etc.)	1. Advise Product Owner on solution strategies 2. Lead the initial sizing of stories 3. Lead the user story breakdown into tasks within the scrum team.
How do I contribute during feature grooming?	1. Set up feature grooming sessions with the scrum team ahead of the sprint the feature/story is slated for. 2. Introduce features and stories to the team 3. Walk the team through key aspects like business case, priority, users, acceptance criteria, etc. 4. Gather feedback from the team regarding sizing and open questions. 5. Close all open questions prior to initiation of sprint.	1. Ensure all stories have proper sizing. 2. Ensure all questions from the team are addressed by the Product Owner prior to sprint initiation	1. Lead the scrum team in ensuring stories are ready for intake, and all necessary details have been provided by Product Owner (description, acceptance criteria, size, business needs, etc.) 2. Advise team on solution strategy, architecture, tech-specs, etc.
How do I contribute during sprint planning?	1. Ensure that the stories are being pulled in as per priority 2. Ensure all completed stories from last sprint can be accepted as per acceptance criteria and definition of done.	1. Lead the recurring sprint planning sessions. 2. Lead team in pulling prioritized stories as per team velocity. 3. Ensure last sprint’s incomplete stories are properly split and re-sized. 4. Ensure all stories in completed status are accepted by Product Owner. Document if any completed story cannot be accepted by PO. Work with Product Owner to refactor such stories. 5. Work with Tech Lead / Architect to ensure maximum utilization of team’s bandwidth for the sprint.	1. Lead work breakdown and task sizing 2. Lead work distribution within the team
How do I contribute during sprint demo?	1. Lead the recurring sprint demo, ensuring necessary stakeholders are invited and present. 2. Lead demo of accepted stories and features from the sprint. 3. Gather stakeholder feedbacks, perform necessary follow-ups, and creation of pertinent refactoring stories and features.	1. Present key team metrics from the sprint, and the outlook for the following sprint. 2. Be the voice of the team where needed in answering stakeholder questions.	1. Walk the stakeholders through the technological aspects of the solution as necessary.
How do I contribute during retrospective?	1. Gather feedback from the team regarding areas of improvement, and their thoughts on how features/stories can be better developed to aide the team’s work. 2. Present improvements incorporated since last retrospective. 3. Provide thoughts for process improvement.	1. Lead the recurring retrospective session 2. Gather feedback from the team about areas of improvement. 3. Provide thoughts for process improvement. 4. Walk-through action items from the previous retrospective and the changes introduced.	1. Gather feedback from the team regarding areas of improvement 2. Provide thoughts for process improvement.

2. How do we define “done”?

The standard definition of “done” employed by majority of Agile teams consist of criteria such as:

1. Code completion,
2. Unit tests passed,
3. Code review completed

In my experience, however, I have found it is best to define “done” in a way that adds to the feedback loop which is a cornerstone of agile. Here is how I define “done” for features and user stories within any new team I’m building:

1. Construction completed: All coding tasks within the entity (user story/feature) should be completed and integrated. Integration is a key part of feature definition, since a standalone feature provides no value to end-user. This factor should be kept in mind during backlog grooming.
2. Testing completed: Unit and system testing should completed. In case of a feature’s definition of done, integration testing should be completed as well.
3. Stakeholder review and signoffs: Appropriate stakeholder reviews should be completed as a part of sprint review to consider a story/feature “done”.
4. Backlog refined: All identified and related future developments and potential enhancements should be entered into the backlog by Product Owner, and traceability captured. Based on stakeholder feedback, any additional changes or bug fixes should be documented as new stories for future sprints.

This approach ensures comprehensive coverage and also future-proofs the backlog by identifying and documenting potential enhancements. Stakeholder engagement through reviews and sign-offs guarantees alignment with business needs, reducing rework. Additionally, creating fallout stories from stakeholder feedback promotes continuous improvement, enabling the team to address issues promptly and enhance features effectively.

3. How should we size stories?

The most common challenge faced by a team starting its Agile journey is laying down a strong foundation behind the method to size their stories. While the Agile principles leave the option to the team to define the sizing framework in a manner that suits them best, I have seen new teams lacking the maturity of experience struggling with this.

There are several techniques that are utilized across the Agile industry, and they all are well thought out and powerful when implemented right. However, in my experience I have come to see that the following sizing mechanism works best for new teams:

1. Use person-day as the unit of story size: If a story is estimated to take 1 person 1 day to deliver it, categorize it as a 1 point story. Similarly, if a story would take a person 3 days to deliver, it would be a 3 point story.
2. Break down large stories: Generally – if a story is over 5 points, more often than not it has not been broken down efficiently. Refine the story to effectively divide delivered functionalities into individual stories. However, be cautious with this rule of thumb, since there are no absolutes when it comes to story sizing.
3. Feedback loop: Estimation seldom align with reality. Scrum Master should constantly monitor sprint velocity by taking into account estimates vs actuals of story sizes. Together with Tech Lead and the team, Scrum Master should take these findings to better define story sizes in subsequent sprints

In conclusion, through incorporation of comprehensive coverage, stakeholder engagement, and continuous improvement, teams can enhance their Agile processes and deliver high-quality products consistently. While my experiences have helped me build my own bag of tools that I have employed successfully in my Agile engagements, it would be short-sighted to consider them as the only solutions available. What makes Agile a wonderful methodology is its inherent trait of democratizing structural decisions within the team. If you are new to Agile, feel free to embrace these best practices to streamline workflows and ensure alignment with business goals, driving innovation and excellence in every sprint. However, in doing so, you should not forget that Agility within Agile is not only welcome but also necessary.

I invite you to connect with me for questions specific to your team, and to share your thoughts and lessons learned as we continue to refine our Agile journeys together.

Additional Resources:

• Atlassian’s article on Agile roles and responsibilities is wonderfully crafted and is a comprehensive document on laying the foundation right. https://www.atlassian.com/agile/scrum/roles
• I’d be remiss if I did not mention a few other story sizing techniques that I have experienced across teams, and are powerful when implemented well.
  • Planning Poker: This is a collaborative estimation technique where team members use cards with numbers (typically Fibonacci sequence: 1, 2, 3, 5, 8, etc.) to estimate the size of a story. Each member selects a card in private, and then everyone reveals their cards simultaneously. The team discusses the estimates, particularly any outliers, until a consensus is reached.
  • T-Shirt Sizes: This method uses T-shirt sizes (XS, S, M, L, XL) to categorize the relative effort required for each user story. It’s a quick way to give a rough estimate without getting into too much detail.
  • Story Points: Story points are a unit of measure that represents the effort required to implement a user story. They take into account the complexity, risk, and amount of work. Teams often use relative sizing to compare stories against a baseline story of known size.
  • Affinity Estimation: This technique involves sorting user stories into groups based on their relative size. The team collaborates to place each story into a size category (e.g., story points or T-shirt sizes) by comparing it to other stories in the backlog.
  • Bucket System: In this method, stories are grouped into buckets that represent different size categories. Team members discuss and move stories between buckets until they agree on the appropriate size for each story.
  • Dot Voting: Each team member is given a set number of votes (dots) that they can use to vote on the size of a story. The story is then assigned a size based on the majority vote or a consensus reached after discussion.
  • Three-Point Estimation: This technique involves estimating the best-case (optimistic), worst-case (pessimistic), and most likely scenarios for a user story. The final estimate is often calculated using a weighted average of these three values.