Sprint Retrospective Meeting - Facts & Rules

Source:  Agile Project Management with Scrum by Ken Schwaber

Duration:

1.     Time-boxed to 03 Hours (Three Hrs).

2.     Occurs after Sprint Review & Before Next Sprint Planning meeting.

  

Attendees:

3.     Team, Scrum Master, and Product Owner.

4.     The Product Owner is optional

 Retrospective Procedure

5.     All Team members answer two questions:

a.     What went well during the last Sprint?

b.     What could be improved in the next Sprint?

6.     Also team members can think on four Short Subjects:

a.     Start Doing

b.     Stop Doing

c.     Do More

d.     Do Less

7.     The Scrum Master writes down the Team’s answers in summary form.

8.     Scrum Master does not provide answers, but facilitate the Team’s search for better ways for the Scrum process to work for it.

Action Items – At The End

9.     The Team prioritizes in which order it wants to talk about the potential improvements.

10.   Actionable items that can be added to the next Sprint should be devised as high-priority non-functional Product Backlog.

More Details On Retrospective

11.   Type of Retrospectives

a.     Iteration Retrospective

b.     Release Retrospective

c.     Project Retrospective

d.     Surprise Retrospective

12.   Retrospectives Improvements: Retrospective offers multiple improvements.

a.     Improved Productivity

b.     Improved Capability

c.     Improved Quality

d.     Improved Capacity

13.   Steps to Conduct Retrospectives

a.     Set the Stage

In this step, aim at creating an atmosphere where people feel comfortable speaking about things that may not have gone well on the project.

Few techniques:

·         Check-In – Ask everyone to summarize in one-two words what they hope to get from retrospectives.

·         Focus On/Focus Off

·         ESVP - Explorers, Shoppers, Vacationers, Prisoners

·         Working Agreements

b.     Gather Data

Create a shared picture of what happened during the iteration.

Few techniques:

·         Timeline

·         Triple Nickels – Top Five Ideas, Elaborated By Five Groups, Five Times

·         Mad, Sad, Glad

·         Local Strength

·         Satisfaction Histograms

·         Team Radar

·         Like to Like

c.     Generate Insights

This step involves driving meaning insights from the gathered data in previous step and make sense out of it.

Activities done in this step help team interpret and understand implications of the issues before then move on to solving them.

Few techniques:

·         Brainstorming

·         Five Whys

·         Fishbone

·         Prioritize with Dots

·         Identify Themes

d.     Decide What To do

                        In this step, team will decide what they will change and how they will behave differently.

Few techniques:

·         Short Subjects –

1.     What Went Well,

2.     Do differently Next time

3.     Keep, Drop, Add

4.    Start Doing, Stop Doing, Do More, Do Less

·         SMART Goals

·         Retrospective Planning Games

·         Circle Of Questions

e.     Close Retrospective

                        Here team summarizes:

·         What the team decided to keep

·         What to change

·         What we are thankful for

·         Where we can use our time going forward

·         Express Appreciation to each other

Few techniques:

·         Plus/Delta

·         Helped, Hindered, Hypothesis

·         ROTI (Return on Time Invested)

·         Appreciations

Keep Blogging...

Regards,

Arun Manglick

Product Backlog Grooming

Backlog refinement (also called grooming),  advises teams to dedicate 10-15 % of every sprint to this activity.

Key Players:

• Product Owner
• Team
• Scrum Master

Process:

During the meeting, everyone helps prepare the Product Backlog for the sprint planning meeting. This usually includes:

• Adding new stories and epics,
• Removing user stories that no longer appear relevant
• Extracting stories from existing epics, and
• Creating new user stories in response to newly discovered needs
• Splitting user stories which are high priority but too coarse grained to fit in an upcoming iteration
• Re-assessing the relative priority of stories
• Estimating effort for existing stories (T-shirt sizing) (Optional here, to be taken in Sprint Planning)

Benefits/Why is this helpful?

The intent of a "grooming" meeting is:

·         To ensure that the backlog remains populated with items that are relevant, detailed and estimated to a degree appropriate with their priority.

·         Groomed backlog will help streamline sprint planning meetings; otherwise, they can stretch on for hours.

·         When product backlog items contain clearly defined acceptance criteria and are estimated by the team members, the planning process does not have to be tense or overly long.

·         By dedicating a time to backlog maintenance, the team ensures that this preliminary planning occurs prior to the sprint planning meeting.

How this is different than Sprint Planning Meeting:

At this meeting, the Product Owner and the team negotiate which stories a team will tackle that sprint.

·         Time-boxed to two to four hours, this meeting is a conversation between the Product Owner and the team.

·         During the sprint planning meeting, the product owner describes the highest priority features to the team.

·         The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog.

·         PO to answer questions, clarify acceptance criteria, or renegotiate.

·         Team sizes story in story points based on complexity and effort required.

·         Stories are broken down to tasks and tasks are estimated jointly in hours.

References:

http://scrummethodology.com/scrum-backlog-grooming/
http://guide.agilealliance.org/guide/backlog-grooming.html
http://www.capriconsulting.co.uk/difference-between-productbacklog-grooming-sprint-planning-and-elaboration/

Regards,

Arun Manglick

Three Amigos In Agile

Three Amigo is a process to get the various roles in a Scrum team together to have a common understanding about a Feature.

The aim is to create a common understanding and shared vocabulary across these individuals.

Key Players Involved:

• Business Analyst (Could Represent Product Owner/stakeholders)
• Developers
• QA Members

Essentially, this is a meeting during which the business analyst (BA) presents the requirements and tests for a new feature.

The Three Amigos (BA, developer, and QA) discuss the new feature and review the specification. Intent is to make these constituencies to be heavily collaborative (have conversations) around the Acceptance Tests or Acceptance Criteria for each user story.

Aim of the Three Amigos process is to bring:

• Shared understanding of the requirements across the Scrum team
• Shared understanding of the tests across the Scrum team
• Consensus about whether a feature was specified sufficiently and is ready to go into a development sprint.

Here is the process in detail:

·         The BA should begin the session by introducing the feature to the Amigos. Why is the feature needed? Is it like anything they've done before? Is there a visual design?

·         The BA should also present the requirements (prepared prior to the Three Amigos meeting). These will be reviewed by the Amigos, who will provide feedback, identify missing requirements/edge cases. The requirements should be updated in the session until the requirements are deemed ready for development.

·         The BA should then present the test scenarios (prepared before the meeting). These are also reviewed by the Amigos. Feedback is incorporated until there is agreement that the test scenarios cover the feature's expected behavior. This ensures good test coverage.

·         The developer is asked to identify Dev tasks that need to be done before development. For example, do they need access to an endpoint? Do they need to see variants of the visual design? These tasks are assigned and put on the current sprint board.

·         The QA is asked to identify QA tasks that need to be done before feature testing. For example, do they require access to a system? Do they need mock data? These tasks are assigned and put on the current sprint board.

·         Regarding estimating, the Amigos should have a common understanding of the requirements and tests. This is a good opportunity for the developer and QA to provide estimates.

·         The feature/specification should now be designated as ready for development. It has been accepted by the developer and QA and is ready to be assigned to a future development sprint.

Few Things To Note:

·         Timebox the Three Amigos meeting (30 minutes to 1 hour, max). Schedule it to occur one to two sprints before a feature is expected to go into development.

·         To embrace the iterative approach of Scrum, there may need to have several Three Amigo sessions in order to perfect a specification.

·         The developer and QA involved in the Three Amigos meeting should be the individuals who will develop and test the feature.

·         When specifying a feature in the Three Amigos, rather than using technical language (e.g., the JSON endpoint) or plain English (e.g., the financial instrument), prefer to use domain language.

Finally aim is – Accept only those features in development that have been Three Amigo'd, so that features are pulled rather than pushed into a sprint.

References: https://www.scrumalliance.org/community/articles/2013/2013-april/introducing-the-three-amigos

Regards,

Arun Manglick