Foster Effective Agile by Avoiding the ‘How’

Image by Pexels from Pixabay

As Product Managers, we sometimes act as facilitators for various Scrum ceremonies. This can be a difficult role to play, especially when the methodology is not shared across the squads.

Focusing my ceremonies on the ‘why’ and the ‘what’, as well as clarifying the roles and responsibilities within squads really helped me gain efficiency and clarity in my Scrum ceremonies.

Many articles on the Agile methodology explore how it is used by Product Managers. In this article, I would like to reflect upon the various tools and processes we have adopted for two specific ceremonies: grooming (epic validation and estimation) and refinement (user story creation and estimation).

Understanding the Problem

With the Product Managers

If you are both the Product Manager and the Scrum Master in your Scrum ceremonies, what would you want to improve most in your ceremonies?

The product team came up with four problematic areas and some concrete examples:

• Methodology: User stories become technical stories that only developers understand, expectations and requirements are often not met, and blockers are identified late in the process
• Efficiency: Meetings are not always structured and user story estimation tends to be difficult and inaccurate
• Communication: Not everyone participates during meetings, causing ceremonies to become repetitive and less engaging
• Roles & Responsibilities: There is no clear definition of who owns what, which creates a lack of accountability

Once we knew what could be improved in our ceremonies, I wanted to know what my squad felt was most pertinent. If we had to change something in the way we were working, the solution needed to come from all of us.

With the squad

We first looked at our retrospective minutes and found repetitive issues that could be easily solved if we addressed inefficiencies in our grooming and refinement ceremonies, such as:

• The way we estimated our tickets was inaccurate, causing us to re-estimate tickets during the sprint
• Blockers and dependencies were identified in the middle of the sprint, delaying feature releases
• Acceptance Criteria were not entirely met or edge cases were not anticipated in QA, also delaying feature releases
• Technical tickets did not always reflect the final implementation. When creating tickets, we often assumed that we knew how they could be completed and outlined the ‘how’ in the description. However, when we started implementing/testing, we often found ourselves needing to implement design changes, making the acceptance criteria, tests, and estimates useless

To understand how we could improve these two ceremonies, we organized a workshop around answering three simple questions:

1. I am given an epic and need to propose stories: What do I do?
2. I am in refinement and need to give an estimate: What do I think about?
3. I started my sprint and need to work on a story: What is the first thing I should do? What are the steps I should take to mark the story as “done”?

The findings were straightforward:

• Epics were always used as the source of truth for the requirements
• The tickets were estimated in two ways: (1) playing poker by guessing what the others were going to say and/or (2) trying to figure out very quickly how they would implement the feature and guessing its complexity
• When user stories got too long, critical information would often be overlooked which would lead to bugs, release delays, etc.

Based on these learnings, we have decided to first focus on the following two action points:

1. Create a template for user stories that would be short and cover all relevant and important information affecting it (acceptance criteria, edge cases, risks, dependencies, etc.)
2. Improve our estimation system

Finding Solutions

Context

To better help you understand how we conduct our ceremonies at SSENSE, here is some context on how to define our artifacts, as they might differ from company to company:

SSENSE artifacts definition

Feature grooming

During grooming, we focus on the epics, which are owned by the Product Managers. An epic is always linked to an initiative. The Product Manager should come prepared with detailed epics that they will present to the senior squad members. They will ask questions to validate the purpose and acceptance criteria. Once everyone reaches an agreement, senior squad members estimate each epic in “developer sprints” and Product Managers prioritize them in the backlog.

The primary goal of this ceremony is to provide visibility to the squad and the stakeholders on the work that will be delivered.

The secondary goals are to:

• Provide high-level effort estimations for features, and outline their start and due dates
• Manage the backlog: last-minute reprioritization, bug reviews, etc.
• Organize and trace feature history

For the grooming ceremony to be efficient, here are the most important things to consider:

1. Come prepared with a clear agenda shared ahead with time allocation on each epic. That way everyone can read the epic on their own time and prepare their questions
2. Epics have to follow a template that clearly states: happy path, edge cases, in-scope & out-of-scope
3. A groomed epic is ready to be presented to the squad during refinement so the developer can cut it into user stories. If during refinement, developers ask questions about the epic that you are not able to answer, the epic needs to be “re-groomed”
4. Any decision should be recorded in the comments for reference
5. Since the epic is owned by the Product Manager, the developers and QA specialists should treat it as the source of truth for the acceptance criteria
6. The conversation should always relate to the ‘what’ and ‘why’, never the ‘how’

Below is a sample Jira epic. All the coloured fields are created automatically — we automated the process. This helps us ask all the “good” questions during the grooming session.

Epic example from Jira

Story refinement

During refinement, we focus on presenting epics, creating user stories, and estimating them. A user story should always be linked to an epic. Here, the Product Manager will present the epics and answer questions along with senior squad members who participated in the grooming ceremony. Then, the developers will create user stories and estimate them.

The primary goal of this ceremony is to ensure that everyone participates in clarification and estimations.

The secondary goals are to:

• Empower the developers and QA specialists to own requirement clarity
• Produce accurate and high-fidelity estimations
• High-fidelity of estimation for few sprints ahead

For the refinement ceremony to be efficient, here are the most important things to consider:

1. Just as with the grooming ceremony, you should come prepared with a clear agenda shared ahead. This gives everyone a chance to understand the epics, prepare their questions, and consider the user stories that need to be created. If you have several epics to present, you can also assign a developer to each epic, the developer’s goal will be to come prepared with the suggested user stories.
2. User stories have to follow a template that clearly outlines: (1) A small, meaningful, and adequately non-technical summary in the title. (2) In the content: acceptance criteria, edge cases, risks and dependencies, etc.
3. For each user story, the description should be focused on the ‘what’ and the ‘why’, not the ‘how’. This helps to avoid creating technical stories and prematurely locking-in on a specific design. This may be the most important rule of all, and is usually hard to follow because developers often fixate on the ‘how’.
4. A good estimation cannot focus on the ‘how’ because the execution process can change but the estimation never changes.

Below is a sample user story on Jira. Once again, all the coloured fields are created automatically to lead us to ask the right questions during the refinement ceremony.

User story example from Jira

The secret tool

I will now present my favourite tool of all, the one our squad created to provide high-fidelity estimations and avoid discussing the ‘how’.

Discussing the ‘how’ during grooming and refinement can be “dangerous” for many reasons, and not only because your estimations might be off. Here are a few cases to consider:

• If the ticket defines how it needs to be done rather than what needs to be done, you dictate the solution at the start of the sprint, rather than empower the team to find the best solution and change their mind within the sprint. When we did this, the original thinking regularly ended up being wrong and we needed to update the description and change the estimate, or worse just ignore what we said earlier. This causes a lot of useless back and forth and stress on the team.
• If the developers think about the execution process when estimating the ticket, the estimate will be skewed because it will depend on the seniority and the skills of each developer. The estimation should be the same for every ticket, the velocity, however, will reflect the seniority and the skills.
• If the refinement of a ticket is about the ’how’, you might end up in an endless debate. This will prevent you from estimating a good number of tickets and building your backlog in the allotted time. There is value in clarifying the ‘how’ and it is one of the steps of story development (the design sub-task). The goal of the estimation time is to clarify ‘what’ you are trying to do for the users and ‘why’.

The most popular and sensible way to estimate tickets is to compare each user story to a similar story that was previously done and allocate its points proportionately. However, referencing the past is not always possible, especially when the squad or the nature of the project is somewhat new.

This is where our secret tool comes in handy. Whenever the team disagrees with estimation and starts talking about the ‘how’, we create a grid that helps us find the right estimate and maintain our focus on the right questions.

In order to build your grid, you need to identify the criteria that influence your estimation. Then, you will need to evaluate each story point based on these criteria. Once the grid is ready, whenever you have a story, you ask the team for each criterion and their estimation. Your final estimation should be the highest estimate.

Estimation grid example

For our team, here are the criteria that we use:

• Complexity: Does it require a lot of analysis? What is the scope of the analysis?
• Impact: Does it touch critical processes or not?
• Deployment: Does it require DevOps, synchronization, etc.?
• Uncertainty: Is the subject matter expert inside or outside the pillar?
• Repetition: Does the same action need to be performed repeatedly?
• Test cases: Are a lot of test cases required?

Measuring the Impact

If you only want to take-away three rules from this article, they should be:

1. Focus the grooming and refinement discussion on the ‘what’ and the ‘why’
2. Use a grid for estimation when there is disagreement within the squad, or when the discussion deviates from the aforementioned point 1
3. Clarify ownerships: Product Managers should own the epics (source of truth for exhaustive acceptance criteria) and developers should own the user stories

After six months of adopting this approach, we have noticed two big changes in our team dynamic. Firstly, everybody now feels empowered. The developers own the content of the user stories, and the epics act as a point of reference and clarification, available at all times to steer the general direction of user stories.

Secondly, communication and transparency have grown within the team. The scope of user stories can now be properly defined, and their process can be clearly outlined in with sub-tasks. This helps developers and QA specialists structure their work, and allows Product Managers to track each story at every stage of development.

Thank you to Thomas Santonja for his help with refining this process and implementing it across the squads.

Editorial reviews Deanna Chow, Liela Touré, & Prateek Sanyal.

Want to work with us? Click here to see all open positions at SSENSE!