Agile

In Scrum, each sprint is required to deliver a potentially shippable product increment. This means that at the end of each sprint, the team has produced a coded, tested, and usable piece of software.

Show what was achieved in the Sprint.

Focus on the outcome, what the benefit is. Not report status on actions.

Changes

1. 'Refactor product in production' => 'Show the product and gathered requirements'
2. 'Meeting with workload team' => 'Show product and tell' (engagement)

The sprint planning meeting is the kickoff to every sprint.

The Planning meetings typically consist of two parts. In the first part, the team and product owner identify the backlog items that the team feels it can commit to completing in the sprint, based on experience with previous sprints. These items get added to the sprint backlog. In the second part, the team determines how it will develop and test each item. They then define and estimate the tasks required to complete each item. Finally, the team commits to implementing some or all the items based on these estimates.

Questions

• Do we already have a theme for the sprint (Increment) to formulate the sprint goal?

The 12 Agile Principles are:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Source: 12 Principles Behind the Agile Manifesto | Agile Alliance

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.

The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.

Source: Scrum Guide | Scrum Guides

Sprint is one timeboxed iteration of a continuous development cycle. The sprint supports the team’s ability to work using Agile processes and tools.

During the planning meeting, typically held on the first day of the sprint, the product owner works with the team to identify those stories or backlog items to complete in the sprint.

Retrospecitve is about self-reflection of the team.

No matter how good a Scrum team is, there is always an opportunity to improve. Although a good Scrum team will constantly be looking for improvement opportunities, the team should set aside a brief, dedicated period at the end of each sprint to deliberately reflect on how they are doing and find ways to improve. This occurs during the sprint retrospective.

Epics are user-centric groupings of what a user does. They are typically the way we first think of the users’ functional needs; our job is to describe detail.

• Typically, an epic is the highest-level grouping and is not used for estimation because it can’t really be “complete.”
• Epics are large and span multiple value areas, sprints, releases, and features.

Features are system-centric groupings of what a system does. They are useful when having release planning discussions to keep conversations at an appropriate level of detail.

• Features provide a greater level of detail that describes a block of functionality that delivers a new capability.
• Features should be defined sufficiently to be estimable and testable, although small enough to fit in a release – but a feature can span multiple sprints and be worked on by multiple teams.

User stories are short stories about people who use the product. They contain a name, a brief narrative, acceptance criteria, and conditions for the story to be complete. User stories focus on exactly what the user needs without going into the details on how to achieve it.

A description of a user story should include a name, a brief narrative, acceptance criteria, and conditions for completion.

Tasks are the technical work that a development team performs in order to complete a product backlog item (PBI). Most tasks are defined to be small, and represent no more than a few hours to a day or so of work.

The sprint backlog should contain all the information the team needs to successfully plan and complete work within the time allotted without having to rush at the end.

Before start planning your sprint, you’ll want to have created, prioritized, and estimated the backlog and defined the sprints. 

A story point is a metric used in agile project management and development to estimate the difficulty of implementing a given user story, which is an abstract measure of effort required to implement it. In simple terms, a story point is a number that tells the team about the difficulty level of the story. Difficulty could be related to complexities, risks, and efforts involved.

Story points are a useful unit of measurement in agile, and an important part of the user story mapping process. A number is assigned to each story to estimate the total effort involved in bringing a feature or functionality to life.

A Product Backlog Item (PBI) is a single element of work that exists in the product backlog. PBIs can include user stories, epics, specifications, bugs, or change requirements. The Product Owner of an Agile team compiles and prioritizes the product backlog, putting the most urgent or important PBIs at the top. 

Are you practicing Professional Scrum, or are you just going through the motions and only holding Scrum Events?

Learn more about Professional Scrum.

A sprint goal is an overarching objective to be accomplished during a sprint. The sprint goal is frequently elaborated through a specific set of product backlog items. A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner.

Estimating tasks will slow you down. Don't do it. We gave it up over 10 years ago.

One of the most popular formats that Developers use for the Daily Scrum involves each Developer sharing in turn what they did yesterday to help the team meet the Sprint Goal, what they will do today to help the team meet the Sprint Goal, and whether they have any impediments.  It can be a useful structure, but if the team follows it robitcally, they might miss the POINT of the Daily Scrum.  At the Daily Scrum, the Developers should be inspecting progress towards the Sprint Goal together and talking about how it's going.  This isn’t just a burn-up chart, or three questions to tick off. The Daily Scrum is a frank discussion about progress and to determine whether the team needs to adapt its plan.

Source: The Daily Scrum Event: 5 Surprisingly Common Misconceptions

Another common misconception about the Daily Scrum is that the Scrum Master should facilitate the meeting.  In reality, while the Scrum Master should ensure that the Daily Scrum takes place, they are not required to facilitate the meeting.

The Daily Scrum is a synchronization meeting for Developers, and no one else is required to attend.

Scrum Masters might decide to facilitate the event if the Developers are struggling to maintain the timebox or need additional coaching.

Source: The Daily Scrum Event: 5 Surprisingly Common Misconceptions

As an activity, Product Backlog refinement has the following purposes in Scrum:

• Clarifying items on the Product Backlog that are too unclear to start work on. This is preferably done directly with the people you’re building the items for (the stakeholders)
• Breaking down items that are too big to pull into a Sprint (which generally also means that they’re too unclear)
• Re-ordering the Product Backlog as needed to make the upcoming Sprints as smooth and valuable as possible
• Adding or removing items from the Product Backlog as new insights emerge
• Estimating the effort involved in implementing particular items. This does not have to be as ‘formal’ as assigning story points (an optional practice in Scrum), T-shirt sizes or whatever sizing technique you use. A gut feeling (“Yeah, we know well enough what needs to be done and it feels doable in a Sprint”) is fine too

Scrum is an empirical process control framework.

Empirical means to runs experiments to improve the product.

Meetings in Scrum

• Sprint Planning
• Sprint Daily Sync
• Sprint Review
• Sprint Retrospective

Additional meetings

• Sprint Review Preparation
• Sprint Review Demo Preparation
• Sprint Review Dry Run

Tips

• Epics are the first way we think of features, such as contactless pay.
• Epics can be improved over time by delivering more features.
• Features CAN (but not necessarily) be viewed as the minimum viable release for a single function of a system.
• Try to ship features as bundles of functionality.