Insights on Definition of Ready (DoR)

The Definition of Ready (DoR) and the Definition of Done (DoD) are checklists of the work that must be completed before a product backlog item (PBI) can be considered to ready for release.

The Definition of Ready (DoR) defines the ready state. In simple terms, a epic/user story needs to meet some criteria (or conditions) before it can be picked up for a release/sprint. The DoR collects all the conditions necessary for a user story/epic to be developed in the current sprint/release.

The  PO/PM is accountable and responsible for the DoR that must have all details required by the organization, and description of the epic/story in consultation with the team.

A Definition of Ready (DoR) Defines Pre-Conditions.

A well defined and DoR compliant epic/story will help everybody associated with information that will be useful not just for the development team but also the stakeholders, marketing and sales people.

The stakeholders will benefit from the DoR by knowing the business value/ROI expected from the epic.

The sales people will be delighted to know the expected value/purpose for the customer. That will help them in their sales pitch.

Every required detail should be in the Epic/Story before the team can start grooming (not commit) the work item before they pull it up in sprint planning.

Focus on the description (canonical format), acceptance criteria, estimates, size, start date, due date and all other details that apply.

Backlog grooming: The focus here should be more on creating not only a strong backlog but also a healthy one. Hence, the DoR is important.

Grooming the product backlog should ensure that items at the top of the backlog are ready to be moved into a sprint so that the development team can confidently commit and complete them by the end of a sprint.

The backlog grooming focus should be more on the health of a strong backlog rather than the immediate next sprint.

What DOR means…Accountability

Product Owner/Product Manager

• Add a description – Description should be in the canonical format – Either, Given-When-Then, or As a Role-What-Result.
  • For user story- It will be interesting to note that there are tools like cucumber, gherkins, etc. that can automate acceptance tests based on the canonical format. Hence, it is very important to follow the approach.
• Prioritize the Epic/Story – (use prioritization techniques like WSJF (weighted shortest job first), Customer demand, Ranking, MoSCoW, Five Why’s, KANO, etc.)
• Assign a high-level Size for the Epic. (the context of size here is to give it a number (Fibonacci series), or t-shirt size (S, M, L, XL, XXL) and not estimated effort, time)
• What value is it adding to the product –
  • Is it an organisation initiative?
  • What is the customer perceived value? – This information is important for the stake holders and sales people.

What DOR means…Consulted

Architect

• Scope and refine the epic/story based on technical investigation.
  • Carry a feasibility study and document possible approaches to develop the epic/story (POC, Spike) Note: POC and Spike are not the same.
• Can assign a preliminary estimate to the Epic/Story. (the context of estimate here is to give it a number (Fibonacci series), or t-shirt size (S, M, L, XL, XXL) and not limited to the estimated effort, time). The development team has the final say on the effort estimate.
• Highlight any architectural risks/challenges.

What DOR means…Responsible

Development Team

• Understand the description, acceptance criteria and scope.
• Refine the preliminary estimate in consensus with PO and architect.
• Give an Estimate for the story (effort estimates should be based on– Complexity | Uncertainty | Dependency) . (The estimations can be done in the sprint planning, better if done during the backlog grooming)
• Assign an owner and commit. (Should be done in the sprint planning)
• Create tasks for each story. (Should be done on the first day of the sprint. If possible, do it during the sprint planning itself)

There are different thoughts on creating tasks. But, it has been proved in the product organizations that creating tasks will help in getting more clarity in the burn-down charts and thereby help in tracking the correct progress. However, there are other matrices to track the progress that should be considered once the team becomes mature with this process. There are more chances of team getting corrupted when they start understanding the system better and, over a period the velocity chart shouldn’t be the only data to rely for value output.

What DOR means…More details

Capture all engineering level discussions, constraints, dependencies, underlying assumptions & the finalized approach. Highlight any engineering level risks/challenges with other discussion points.

Tip for creating a healthy and strong backlog

Conduct JAD (Joint Application Design, or Joint Application Development) sessions, if needed.

• Simplify — consolidate months of meetings and phone calls into a structured workshop.
• Identify — issues and participants.
• Quantify — information and processing needs.
• Clarify — crystallize and clarify all requirements agreed upon in the session.

What is Definition of Ready DoR for an Epic/Story

Definition of Ready for an Epic

Detailed Appropriately

• Dependencies are identified and no external dependencies would block the PBI (Product Backlog Item) from being completed.
• Details are sufficiently understood by the development team so it can make an informed decision as to whether it can complete the PBI.

Emergent

• The feature shouldn’t be static. As the project progresses more information (description/user stories) can be added.

Estimable

• The items at the top of the backlog have more accurate estimates.
• The lower priority items are estimated at a high level and can be re-estimated as the team gets more information.

Note: Sizing – Not all XXL size will require the same effort. Similarly, not all S or M size will require any less effort. One size doesn’t fit all. Practice relative sizing.

Prioritized

• Business value is clearly articulated. •Performance criteria, if any, are defined and testable.

Definition of Ready for User Story

Independent

• The work item should be independent (self-contained and possible to bring it to progress without any dependency on other work items or external resources).

Negotiable

• Should have enough room for discussion regarding its optimal implementation

Valued

• What value it provides to the user, should be clear.

Estimated

• In story points (note the story points is a unit-less unit, i.e., it may not mean 1 point = 1 day, or a couple of hours).

Note: Estimation – Not all XXL stories will have higher story points, and not all S, M   stories will have less story points. It is based on the level of Complexity, Uncertainty, Dependency

Small

• The PBI (Product backlog item) must be estimated and small enough to be completed in one sprint.

Note: Slicing – there are various techniques – Vertical, SPIDR (Spike, Path, Interface, Data, Rules) – whichever applies for the story can be used.

Testable 

• Acceptance criteria are clear and testable.

---

We will discuss Definition of Done (DoD) in the next blog.

Advertisement

Agile Manifesto Revisited

In the current wake of COVID 19 while we all are confined to our homes, it is is not a punishment rather if we look at it with a positive aspect, we now have more time to dedicate to our families our hobbies and our growth. This pandemic has shown us the path to some great opportunities ahead.

Likewise, the agile manifesto that was drafted way back in 2001 did consider all this. It said that – While the items on the right are important, we value the items on the left.

Now, it should be…”While the items on the right are important, the valued items on the left will not reach it’s effectiveness without the items on the right“.

Individuals and interactions over processes and tools

• 

We have to rely on processes and tools to have more interactions with our teams

Many employees across the world found themselves using videoconferencing for work for the first time. They assumed it would be like using FaceTime but encountered several issues, including a lack of device interoperability, poor desktop-sharing experiences, and difficulties adjusting audio devices. But, some tools can help us function just like the way we operated from office. The difference being now we are more connected to our families while our peers are on screen. 

Working software over comprehensive documentation

• 

Overwhelmed customer service teams on the vendor side couldn’t respond to the questions of so many new users. Multiple vendors claimed that their inquiry volumes increased by an order of magnitude during that period. They don’t want to rely on documentation alone. They want to see it, experience it. And, that’s where we will need more effective tools to do so.

Customer collaboration over contract negotiation

• 

We do need a contract in place before we start executing the project and the customer collaboration relies extensively on the collaboration tools like Skype, GoToMeeting, Slack, Zoom, etc. 

Research shows that active users, who rely heavily on sending documents for collaboration, are concerned about the risks inherent to sharing documents online. Although SaaS providers have demonstrated the security of their cloud storage offerings with encrypted networks and permission control systems, customers are still unsure of how safe their documents and personal information are when using tools. And, that’s what is the need of the hour.

Responding to change over following a plan

• 

Times have changed and so has the focus. The world wasn’t prepared for the pandemic and hence had to enforce new laws and introduce changes in the way we used to function earlier. Responding to change was mostly limited to the changes in the client requirements, we never thought that we will have to change the way we operate, commute, and communicate. 

Once all this is over and as enterprises resume normal business activity, they will notice that an effective collaboration strategy needs to align the business and technology objectives and coordinate work streams across cross-functional teams. Current pilots are only part of the holistic adoption assessments needed. 

To succeed, tech and business leaders will have to advocate for management support, cultural change, and adoption strategies for Employee Collaboration instead of simply defining a SaaS roadmap.

• 

Change?

“There is an expiry date for all. No body and nothing are indispensable. There are no guarantees to anything. Nothing lasts forever.”
All that exists has to perish and go back where it has come from. That’s the only constant. That’s nature. Everything that is created has an end and MUST have an end or it becomes monotonous and loses value. If there is no end then there is no room for the new. If we want a change then we have to change that which is now. There is no such thing as forever. If there is then it is death. I am yet to see one who can prove that life is forever, it is death that is forever. Thoughts change, feelings change, responses change, ideas change. The word idea can be treated as a short term for i-Dream / i-Death. The death of the old and the birth of the new becomes an ‘idea’. 

‘I’ has to die to give rise to the new. The ‘I’ is the ego. Let it die, or better,……….. kill it!

‘We change the world by changing the way we perceive the world, the way we think about cause and effect, by altering our beliefs of true and false, right and wrong’.In this material world we believe in buying the latest. Why? Because we all want a change. We get bored with the new and again want a change. For this simple reason even the furniture re-arrangement in our house after a while makes the room look new, but then after some time that too becomes old and needs a change. Don’t be that rickety old piece of furniture that eventually gets replaced. Be the change!

Our conditioned ways of looking at things prevent us from taking the plunge, or allow anybody else to take the plunge.

We are so attached and used to our designations and comfort zones that we do not want to let go for the fear of losing all. We are so much obsessed with power that we forget to empower.

Transformation is the need of the hour. Do introspect and see if you value change, or you are the bottleneck!

In the software world, what was new yesterday is legacy today. Keep upgrading keep learning. Embrace change rather push back. Change or be prepared to be changed.

Don’t fake it, if you don’t have it!

That reminds me few lines from the poem ‘IF’ by Rudyard Kipling –
If you can make one heap of all your winnings

And risk it on one turn of pitch-and-toss,

And lose, and start again at your beginnings

And never breathe a word about your loss;…

‘What is the theory behind what we do? Is it really about what we want, or need? Or, has it gone untested for so long that we no longer question it?’

In the land of opportunities that is the United States; It took 43 presidents before the change;
44th was the president who was not a white American- Barrack Obama.

Who wants a change?

The magic lies in changing the way we think in order to change the way we live.

Business Realities

Businesses want to reduce cost and risk while increasing revenue. To succeed as a software developer, don’t try to sell working software for less money than others; instead, reduce cost, reduce risk or increase revenue for those companies. I will discuss a few ways to do these things, and do them well.

1) Provide Guarantees.
So the other person provides a lower hourly cost. So what? Does that mean that the total cost is going to be less? Most people that deal with software contractors know that an estimate is rarely worth the paper it’s printed on. That’s why fixed-price and fixed-date contracts are so appealing to customers: It moves the risk from the shoulders of the customer to the selling organization. As long as the buying organization is certain to make money, hourly rates won’t matter. (How do you compare $6/hour and “We think it’ll take about six months” to “$10,000 and it will be done in three months.” How about to “I’ll take 30% of gross revenues. If you don’t make a dime, I don’t make a dime…and this will encourage me to make it good enough to re-sell”)

2) Analyze the business and provide a better solution

“Customers Don’t Know What They Want. Stop Expecting Customers to Know What They Want.”

Joel Spolsky

In other words, the attitude of “Just give me the requirements” fails because it has the customer solving the problem; the software developer becomes just a glorified technical writer that knows how to write in the language of a machine.

3) Dramatically decrease the defect rate
Are people willing to pay for quality in software? Sadly, generally, the answer is no. Quality in software is hard to measure; unlike automobiles, there is usually no crash or endurance tests to compare against, especially for custom software. Yet we all know that plumbers, electricians, and roofers with a reputation for quality have more work orders than they know what to do with. Producing software with less defects, that is usable, that does what the customer expects will net a major competitive advantage for years to come.

4) Create well-documented, maintainable code
Despite all the jokes about job security, companies want well-documented, easy-to-understand and easy-to-change systems. This allows them to reduce risk, and, as we’ve previously discussed, reducing risk has tangible, measurable value to a company. The great thing about increasing the value of what you sell is that you can now charge more for it.

5) Provide better feedback
If you prioritise every feature, you can work on the most important features first. A series of small releases gives the customer the most important features first and the opportunity to provide feedback. This is not a new idea; it is one of the core ideals of the Extreme Programming model, and it’s an excellent way to give the customer more while costing you less. (Think about this: Most large projects run late and over budget. Many small projects do not. Instead of “biting off more than we can chew” next time, why not refuse to run a large project and instead run a series of small projects?)

6) Show the customer how you will make them money or allow them to cut costs.
This one is a no-brainer. It’s easy to charge more for your services and still win the bid if you are selling something fundamentally different: This is why McDonald’s franchises sell for more than Jerry’s Pizza Shack franchises. Imagine the two sales pitches:

Jerry’s: “Hey, for $10,000 and 3% of your sales revenue, I’ll let you use my name, my sign, my recipes, my suppliers for food, cups, plates – the works!”

McDonald’s: “For $1,000,000 and 8% of your sales revenue, we’ll give you everything Jerry does – plus throw in a lease on a furnished building in residential area X. We’ll promise no McDonald’s competition (except the ones you own) in a 50-mile radius of your store. We’ll provide management training for your people. In fact, here’s a breakdown of our 200 stores in areas with a similar population to X, and their sales compared to expenses for the first five years of business. As you can see, since 1995, only 10 of those stores failed to be profitable within three years, and they were all profitable within five years.”

Conclusions
From the last example, you can see that McDonald’s and Jerry’s are selling two fundamentally different things. They both seem to “solve” the same problem: “I want to own a fast-food business.” McDonald’s chooses not to compete on price; instead, they compete on delivered results.

Most banks compete on delivered results for investment. While they may occasionally advertise that they have low or no minimum balance, it is far more common to hear about a low rate for a loan or a high rate for an investment. If we are to survive the coming bust, we must Promise and Deliver Results. These results must substantially differentiate us from other, cheaper competition.

If you try to build a house and base every decision on cost, you will probably get what you deserve. Most people know this, and factor other things into the decision. As the software industry matures, we must learn to provide and market those “other things.” In order to survive, we must stop being glorified technical writers or creative story tellers and become businessmen…and the need for good businessmen is not decreasing, but instead it is constantly increasing.

Retrospective using the 4L theme combined with Tuckman’s Model

In the previous article we learned how to use the 4L technique for a retrospective and how effective it proved to encourage the team to talk and discuss points that in a normal day wouldn’t be possible. It is one of the effective ways to resolve conflicts in a group.

In this article we will learn more on how we included Tuckman’s model in the 4L Retrospective technique.

• 

Purpose

Being true to the Spotify model wherein the focus is on autonomy we saw value in merging 4L (Liked, Loved, Lacked, Longed) + Tuckman (Forming, Storming, Norming, Performing). This helped in identifying where we need to focus on keeping in mind the organizational goal towards Growth. We will call it Tavision. Tuckman’s model helped us to identify the correct state we were in and identify ways to improve on those and move to the next level.

• 

There are other models too that could give similar results like the Cynafin framework which is more aided towards decision making. However, we choose the Tuckman model because you also need to know the maturity of your teams in adapting to new ideas and ways of doing things. Cynafin at this point was for an advanced stage of doing our retrospectives.

The Agenda (10 Minutes)

Before starting with the retrospective, the IM took 10 minutes to explain the agenda.

• 

For that IM used the Five levels of conflict:

1. Intra-Person– Personal challenges – this has to be solved at a personal level, not with the squad.
2. Inter-Person – Conflicts between two or more individuals in the squad. This has to be sorted between the individuals or with their manager.
3. Intra-Squad – Challenges within squad w.r.t to the sprint work and achieving the sprint goal.
4. Inter-Squad – Challenges with other squads in achieving the sprint goal.
5. Intra-Organization – Challenges at the organization level that needs to be addressed by the leadership.

The agenda was set – the squad was to discuss only on the conflict level 3 and 4.

The Execution

(Total 1 hour, can extend to 2 hours depending on the size of your team and experience with retrospectives)

Explain the Tuckman Model (5 minutes)

Once the agenda was set all squad members were explained the Tuckman model.

Tuckman’s model is significant because it recognizes the fact that groups do not start off fully-formed and functioning. He suggests that these phases are all necessary and inevitable in order for the team to grow, face up to challenges, tackle problems, find solutions, plan work, and deliver results.

• 

1. Forming – Made aware of things. Learning.
2. Storming – Chaos. Need maximum focus.
3. Norming – Started working on the solution but still need more focus.
4. Performing – Doing it as expected.

The List

Once the squad understood what was expected from the retrospective. They were asked to come up with points that they thought was in the Inter-Squad and Intra-Squad level of conflict. This was a group activity wherein IM wrote all points from the team on the white board.(15 minutes)

• 

Next Steps

• Each member was asked to place the items on the board into the four quadrants.

• 

Note: There will be instances that many items on the list will be repeated in different quadrants. And, that’s what will initiate the discussion.

• Once all the items from the list were added to the quadrants we formed four groups and asked each group to pick up all items from one quadrant and further distribute those into the four quadrants as per the groups understanding.

• 

• 

• 

• 

Note: Do this for two rounds or till the group comes up with the top items for each quadrant. Let the squads decide the top items that they want in each quadrant. Further, if needed you can initiate the dot voting to identify the top 3,4 or 5 action items in each quadrant.

In this case the items in the Storming phase will be the top most action item.

• Once the squads identify the top action items everybody in the squad would know the correct state of their squad. And, then identify ways to improve on those items.
• As mentioned earlier the execution was based on the 4Ls Technique, you will need: Post-it notes, flip chart paper, white board, pens etc.

THEN IT WAS TIME FOR APPRECIATION WITHIN THE SQUAD AND CELEBRATE THE PAST SPRINT, WITH PIZZA… 🙂

• 

Decision Dilemmas- All about making and taking a decision

At every point in life we have to take decisions. Those decisions, though ours have an impact on many around us. Our friends, family, society, nation, economy, and politics; all are affected by our decisions. So, what exactly is a decision? Is it something that can be ignored or, it is something that is the cause for everything happening around us? Taking a decision also means not taking a decision. Read ahead and you will know.

Decision:

• The act of making up your mind about something.
  • This can be an opinion about somebody or something.
  • Opinion is not judgment – Opinions assist in judgment.
• Decide to do something.
  • To decide to do something also means to decide not to do something.

Example: I decide to start my day early. Meaning, I decide I will not wake up late. It also means that I decide to sleep early…and so on…

Example: We have to decide on which car to buy, where to invest, where to construct house, and so on…

• Decisions can vary from simple ones to complicated and serious decisions.

Types of Decision

• Good Decision.
• Bad Decision.
• Incorrect Decision.

What is the difference?

• Optimal Result = Good Decision.
• Average Result = Incorrect Decision.
• Failed = Bad Decision.

Case study – Starting a Venture

• Decision to start a business – Good decision, can be incorrect or bad decision.
• Decision to quit Job – Good decision, can be Incorrect or Bad decision.
  • Optimal Result – Good Decision – If the business grows and becomes profitable.
  • Average Result – Incorrect Decision – if growth becomes stagnant and eventually stops.
  • Failed – Bad Decision – Would have been good if… Best reason to learn from the failure and start all over again.

Examples of some famous decisions

• Mohandas Karamchand Gandhi decided that India was to be freed from the Queens rule. Not that he was the only one, there were many but his means to free India from the Queens rule was different and shameful for the British that they had to quit.
• Dhirubhai Ambani – wanted to create wealth and he did, not only for himself but for all.
• Larry Page & Sergey Brin wanted to collect and make available the entire information available in the universe. Their college project -PageRank resulted in Google – literally replacing the Oxford dictionary.
• Steve Jobs decided he was wasting his time in college studying subjects that did not inspire him, so he dropped out and took up a calligraphy course.
  • Result – Apple Inc – Mac PC, iPod, iPhone, Pixar studios and the numerous creations that has changed the way we live.
• Bill Gates decided to drop out from college to do more of what he liked doing.
  • Result – Microsoft – his decision opened Windows for us to see the world.

Any decision; whatever the result be -Optimal, Average or Failed; will never take away the value from the decision.

Value

• It’s the depth of the decision.
  • Why it was taken – Purpose.
  • When it was taken – Situation.

Factors influencing decisions

• Family – Upbringing, relatives, elders.
• Society – Cultural, religion, political.
• Education – Level of education – it’s not about being literate – it’s about awareness.
• Experiences – All through our life- personal and professional.
• Hear say– Gatherings, meetings, get-togethers.
• Peers – Colleagues, friends.

Few examples of the decisions we make, take – Decide!

• Decision is needed at every point in life
  • Family decision.
  • Education decision.
  • Career decision.
  • Decisions that are good for one may/may not be the same for all.
  • Decisions can have an impact on one or many.
  • Decisions can be good for some, bad for few, and average for others.
• No decision is Good decision or Bad decision, it’s the value of the decision. If the result is anything other than Optimal, the decision must be re-worked.
• Decisions are only choices. Choices make who we are and who we become eventually!

Ownership

Own your decision. It’s the best and you are the best judge.

Blink! Think! Decide!

4 L’s Retrospective…

There are different ways you can do a retrospective with your teams. Choose the one that will engage your teams and help in identifying few action items that will benefit the teams and in turn the organisation. In this blog we will discuss the 4 L technique. Initially developed by Mary Gorman and Ellen Gottesdiener, it is a simple and popular technique.

What?

The Four L’s is a classic exercise that can be used in agile retrospectives. It helps your teams to look for things they Liked, Learned, Lacked, and Longed For in their iteration, and to take actions based on their shared insight on how they are performing as a team.

As with all retrospectives, 4Ls should be timeboxed. Depending on the size of the team, 30-60 minutes should be enough. If you are doing it for the first time, then allow up to 120 minutes.

The 4 L format can be a great technique to gather data or brainstorm on ideas, etc. It can be a great facilitation tool for conflict resolution, ideations, decision making, etc.

When?

The questions might be subtle but by moving away from the traditional agile retrospective and allowing people to be more engaged from a “heart and mind” perspective can switch up people’s thinking and open-up new insights

Also, be observant and cognizant of the team temperament. There are times your team members will not want to discuss their challenges openly but, talk about those during their water-cooler discussions. Be very attentive and full of empathy for your team. Know that we all are human beings and not machines. We deal with machines and we discuss with people. 4 L is one of the ways to do it.

As an Iteration Manager it is very important for you to know your team temperature. You are one of those leaders who have the responsibility of leading your teams to victory while ensuring that even the new entrants in your team get enough opportunities to participate in the victorious journey. It is no fun to reach the goal with few star performers instead of reaching the goal with everyone involved in the journey. The focus should be on creating a star team (cross-functional) rather stars in a team.

In short encourage your team to:

• Highlight the positive (liked & learned) as well as the negative (lacked & longed for)
• Think mostly from a factual (what happened) perspective, rather than an emotional perspective.

More details…

The 4Ls retrospective is designed to get people to share their thoughts as part of being agile and with the aim of continuous improvement. By asking these questions, it can help open-up the team in to sharing their thoughts, bring out new ideas and foster a sense of being heard. It is based around the following key themes:

• Liked: What did the team really enjoy about the sprint? In particular; what went better than expected? Emphasize on the positive.
• Learned: What new things did the team learn during the sprint? These can be technical things (like the importance of unit testing) or, nontechnical things (like a new and effective way to keep a key stakeholder informed). It can also be about new ways of doing things. It can be around technology, process, software delivery frameworks, etc.
• Lacked: What things could the team have done better during the sprint? What seemed to be missing from the last iteration? This might be something that was unclear or needed to be implemented to ensure that things continue to run smoothly.
• Longed For: What things did the team desire to have during the sprint that were unavailable? Again, these can be technical (like the need for a continuous integration server) or nontechnical (like the desire for more face time with the stake holders).

You need:

Post-it notes, flip chart paper, white board, pens etc.

Process:

1. Hang four posters, one for each L, around the room, titled appropriately. Or, use a white board and divide it into four quadrants. One quadrant for each L.

4 L- Quadrant on white board

• Ask people to individually jot down what they Liked, Learned, Lacked, and Longed For – one per sticky note. When the time is up (3-4 minutes), they silently place their notes on each poster.
• Divide the team into four groups; assign an “L” poster to each group. They read all the notes, cluster as appropriate and identify themes.
• Each group reports out on the themes.
• The entire team (all four groups) then decides how they might use the data. Identify the action items. Share the outcome with the team and stake holders, if required.

How we did it?

Action

Ask each team member to add what they think under each of the four questions. This is best done independently. This process might be best done anonymously in order to help surface any issues which might otherwise not come out. They can indicate when they have finished, or you can set a timer so that you know when to move onto the next stage.

Brainstorm

Scan the ideas for common ground and have a quick discussion. Drag and drop related ideas to combine them for easier voting. Team Retro can also automatically suggest ideas that are similar, saving you and your team valuable time.

Voting

Ask people to independently vote for what they would most like to discuss in the meeting, or items that they feel are the most important. You might want to have 4 votes for example so that they select one under each topic. We used dot voting.

Votes can be tallied for the Discuss stage.

Results (Discuss and identify the action items)

You can now discuss the top voted ideas.  Walk your team through ideas one-by-one and keep the conversation focused.

Create action items based on discussions, assign owners and due dates that will carry through for review at the next retrospective.

Pizza… 😊

Spend the final few minutes to allow the team to appreciate each other and share their thoughts. That will encourage the team to speak up in groups without being overwhelmed.

Researched by- Nabarun Paul, Iteration Manager at Tavisca, A cxLoyalty company