These roles are essential to success with Agile:

• IDENTIFYING THE 'WHY': The Product Owner translates the backlog into consumable pieces, ranging from the initiative down to the story level.
• DEVELOPING THE 'WHAT': The Engineering Team, consisting of Development, QA, and UX, develops product backlog work in accordance with defined Acceptance Criteria (see the March 2021 Agile Hint).
• LEADING THE 'HOW': The Scrum Master is responsible for the development process, protecting the team, and enabling the team to become more efficient and predictable.

Success with Agile is centered around these business themes:

Agile user stories are composed of three core components (courtesy of Ron Jeffries)

1. Card: The description of the User Story.
2. Conversation: Talks that take place throughout a project between the various people concerned by a given feature of a software product (i.e., customers, users, developers, testers). This conversation is mostly verbal, but often reinforced by documentation.
3. Confirmation: Confirmation that the objectives derived from conversations have been reached. The more formal the confirmation, the better.

Story points are a unit of measure to estimate the overall effort that will be required to fully implement an item in the backlog. Story points are typically assigned to each user story:

• Before you organize the stories into releases or sprints
• During backlog refinement, as the team is preparing to bring user stories into a release or sprint

When we estimate with story points, we assign a point value to each item. The raw values we assign are immaterial. What matters are the relative values. A story that is assigned a 2 should be twice as much as a story that is assigned a 1. It should also be two-thirds of a story that is estimated as 3 story points.

What is a Keystone Story?

A Keystone story is a user story that is well understood by the team that can be used as a baseline to relatively point other stories in the backlog.

Examples of Keystone Stories

Example A - The team is reviewing either a new or existing backlog with stories that need to be pointed. The Scrum Master (or person playing the role) will review the backlog with the team. They will identify a universally well known story that they all agree represents a 'medium' size and they point that a 5. That 5 point story is known as the keystone story that all other stories in the backlog will be relatively compared to when story pointing. If the next story is slightly less complex, it could be pointed a 3. If a story is twice as complex, it could be pointed a 13.

Example B - The team is reviewing either a new or existing backlog with stories that need to be pointed. The Scrum Master (or person playing the role) will review the backlog with the team. They will identify a universally well known story that they all agree represents the smallest and least complex story in the backlog, we call it a 'small' and assign it 1 story point. If the next story is twice as complex, it could be a 2. If it's 5 times as complex, it could be a 5.

In both scenarios, it's recommended that teams are using planning poker to ensure the right conversations are happening.

Tips for consistent and predictable sprints

Set a sprint goal

• Make sure sprint goals are defined and documented in sprint planning and that everyone on the team understands the goals so that they can make a commitment.

Commit to the sprint plan

• A sprint plan is a team commitment to getting that work done. If someone is uncertain they need to let the team know. Teams should be confident in their ability to deliver the sprint plan.

Set epic and story level WIP limits

• Get focused on 1-2 epics in any given sprint and determine your backlog WIP limits. Doing this will allow the team to produce value more frequently and burn down the backlog more efficiently.

Focus and swarm

• Stay focused on delivering your sprint commitments over all other work. If you finish early, see if you can help your teammates deliver committed work before pulling the next item from the backlog or anything else.

Examples of Acceptance Criteria

• User can only submit a form by filling in all required fields
• Submission of the same IP can only be made three times within 30 minutes
• User will receive a notification email after successful registration

How to Write Good Acceptance Criteria (AC) For well understood, and high quality AC:

What Is Definition of Done?

For example, if the team does not have automated tests today, do not include that as DoD until it is a possibility. To see both in practice, consider the following sample user story.

"As an online shopper, I want to be able to register online, so that I can start shopping online."

Examples of Definition of Done

• X% of code coverage from unit tests
• Automated tests for stories have been created and passed
• Acceptance Criteria is met
• Security scans are complete and show no critical vulnerabilities

Here are some tips and tricks for Product Owners / BAs to effectively manage a backlog and break down a product into consumable pieces:

1. Clearly define the objectives and goals of the project or product, and ensure that all team members understand them.
2. Identify and prioritize the features and user stories that are necessary to achieve the objectives and goals.
3. Create detailed acceptance criteria for each feature or user story, which will help to ensure that the team knows exactly what is expected of them.
4. Break down each feature or user story into smaller, manageable tasks that can be completed by the team during a sprint.
5. Use tools such as user story maps, feature breakdowns, and task lists to visualize and organize the work.
6. Continuously review and update the product backlog to ensure that it is aligned with the objectives and goals of the project, and that the most important items are being worked on first.
7. Communicate regularly with the team to ensure that they understand the work that needs to be done and that they have the information and resources they need to complete it.
8. Be willing to adapt and change priorities as needed to ensure that the team is working on the most important tasks at any given time.
9. Collaborate with the team to establish clear definitions of done, to make sure everyone is aligned on what "completing a task" means.
10. Finally, involve the stakeholders on the progress of the breakdown work, and seek feedback and buy-in.

Here are some other best practices to follow for breaking down backlog items:

A good user story in Scrum should follow the INVEST acronym, meaning it should be:

• Independent: not dependent on other user stories
• Negotiable: open to refinement and clarification
• Valuable: providing value to the end user or customer
• Estimable: able to be estimated in terms of effort required
• Small: broken down into small enough pieces that can be completed within a sprint
• Testable: able to be tested to determine if it has been successfully implemented

A good user story format is: "As a [user], I want [desired functionality], so that [reason/benefit]." This format helps ensure that the story is value-focused and clearly explains the problem it's trying to solve.

What is a User Story?

User stories are an excellent way to build software that meets users' needs. User stories are simple, clear, brief descriptions of functionality that will be valuable to real users. Another definition (per the FAS Jira Project Template) is "Stories are small building blocks written from a single user perspective and sized to be completed in a single Sprint."

Example of a User Story

User stories can take many forms. One of the most common forms is a statement with the following structure:

As a [WHO], I want [WHAT], so that [WHY].

As a customer, I want to log into the website, so that I can access my profile.

This can also be described as the Role, the Task, and the Outcome.

Story Types

• Business User Story - achieves an outcome supporting the main capability
• Spike - an activity to validate a tool or technique which is new to development
• Refactoring & Re-engineering - revising existing code while preserving the original functionality
• Enabler - Clarifies requirements and testing criteria

The following tips are essential to holding a productive and worthwhile sprint retrospective:

1. Diverse Perspectives: Encourage diverse team members to participate actively in retrospectives. Ensure that everyone's voice is heard, including introverted team members. This diversity of perspectives can lead to more comprehensive insights and solutions.
2. Set Clear Goals: Start each retrospective by setting clear goals and objectives. What specific issues or challenges do you want to address? Having a focused agenda helps keep the discussion on track and ensures that the retrospective is productive.
3. Experiment with Techniques: Don't stick to a single retrospective format. Experiment with different techniques and formats, such as "Stop-Start-Continue," "5 Whys," or "Starfish," to keep retrospectives engaging and fresh. Rotate through these techniques to prevent monotony.
4. Actionable Items: Ensure that the outcomes of retrospectives result in actionable items. Each retrospective should lead to specific tasks or changes that the team can implement in the upcoming sprint. Track these action items to ensure they are addressed. The best way to make an impact is to pick one single action and do it.
5. Continuous Improvement: Treat retrospectives as an opportunity for continuous improvement, not just a routine meeting. Encourage the team to reflect on the effectiveness of past retrospectives and make adjustments accordingly. Continuously refine the retrospective process to make it more valuable and efficient.

Quick tips when experimenting with mob programming concepts: Incorporating mob programming into your development process can lead to improved code quality, increased collaboration, and a more engaged and knowledgeable team, ultimately enhancing the overall productivity and success of your projects.

1. Rotate Roles: Rotate team members through different roles (e.g., driver, navigator, and observer) regularly to maintain engagement and skill development.
2. Set a Timer: Use timeboxing to manage sessions, typically around 15-30 minutes per rotation, to keep the energy level high and prevent burnout.
3. Use a Large Screen: Display the code on a large monitor or projector to ensure everyone can see and participate effectively.
4. Frequent Breaks: Take short breaks between mobbing sessions to recharge and reflect on progress.
5. Include Everyone: Encourage everyone to actively participate, ask questions, and share their insights, regardless of their level of expertise.