Agile QuickTip: Get rid of the ‘Survey 7’ Level-Up to Get Feedback

Get rid of the ‘Survey 7’ to Level-Up the Way You Get Feedback

Surveys can be a really effective tool when collecting feedback or gaining insights from different stakeholders.  Their versatility allows them to be used to get feedback from users and customers as well as to get ideas for improvements from team members.  Surveys can also be really effective as part of a team’s Sprint Reviews and Retrospectives as a tool to gather and visualize different opinions in the same meeting.

I have found that on surveys with questions rating responses from 1 to 10, the number ‘7’ is often the average response.  The ‘7’ becomes the fence-straddler of survey responses: “not terrible, but not good enough to be an ‘8’”.  The ‘Survey 7’ is effectively the non-choice for those that are unsure.  It might make it unclear or difficult to determine what action to take or decision to make.

One technique that might really help is to eliminate the ‘7’ as an option in the survey.  By getting rid of the ‘Survey 7’, it forces respondents to make a choice between the ‘6’ or the ‘8’.  Is it good enough to be rated an ‘8’ or is it just a ‘6’?  By making people choose, we can get better feedback, better insights, and information that is far more actionable.

This Agile QuickTip explains how eliminating ‘Survey Seven’ might have a really positive impact on your team, as well as your product overall.

If you enjoyed this Agile QuickTip, and found it valuable for your teams, make sure to subscribe to our YouTube channel, and check out the rest of the series. You can also follow me on Twitter @GioraMorein, leave a comment below, or send me a message. Don’t forget to check out to see how our training and coaching offerings can help you and your team.

Agile QuickTip: Add Expiration Dates to Your Backlog Items

Add Expiration Dates to Your Backlog Items

If you have a backlog that’s getting out of control, consider using expiration dates to help control the list and streamline your team’s priorities.

Many mature agile teams or scrum teams that have been together for a while might find themselves with a backlog that’s hundreds if not thousands of items deep. On a list this large, it stands to reason that there will be items that have been around for so long they have become stale or obsolete. This can make it difficult to set priorities or work out what items need addressing next. Sifting through your backlog can become an all-day task.

One technique that I find is really helpful is to place expiration dates on backlog items.

This could differ depending on the task. Maybe you’ll choose six months expiration, twelve months or even twenty four months. That way, you have a set amount of time to implement the item, and you would probably feel comfortable that any task that has been around for two years and that hasn’t bubbled up in priority maybe shouldn’t be there at all, and really isn’t worth implementing.

At the very least, the expiration date forces product owners to really evaluate these items and make a decision as to whether to escalate the priority, or to remove them altogether. This way your team can focus on those things that are really the most valuable, and remove the noise of obsolete or out of date items from the to-do list altogether.

I hope you found this Agile QuickTips by Giora Morein valuable, and get a chance to check out previous episodes you might have missed by subscribing to our YouTube channel. Once you’ve done that, head over to our social media pages  Instagram and give us a follow, @GioraMorein.

Agile QuickTip: Use Working Agreements for your Daily Scrum

Use Working Agreements for your Daily Scrum

Have you ever considered that working agreements for your daily scrum might make them a lot more valuable, and help separate the daily scrum from any other meetings you have each day?

Your team’s daily scrum or daily stand up might be one of the most important meetings that they have in the day.

Unlike other meetings, it has been designed in a specific way, to get the most out of it. It’s designed to be very short, for example, and very targeted. It’s designed to be effective and cheap. It’s a different meeting and we should treat it differently.

But how? We all attend so many meetings all the time, how can we help to get a cohesive understanding for what the daily scrum is designed to be like?


One thing that really helps is to have published working agreements that all participants who have signed on for the daily scrum or stand up. These define how we behave, who participates, and practical things like when does it start.

It can even include additional things like “People shouldn’t dial in from cell phones” or “If you’re dialing in from home turn your chair away from the computer monitor.”

By having these published standards, everyone in the meeting understands what’s expected of them, how to behave, and how to expect others to behave. It allows them to hold each other accountable and makes the overall scrum way more effective.

I hope you enjoyed this Agile QuickTip and found it valuable, too! Be sure to go back and check out the rest of the series. We would love to hear your feedback so make sure to leave a comment or send me a message. You can go to to learn more about our training and coaching offerings that could make a real measurable difference to your team.

Agile QuickTip: A Wishlist of Ready!

A Wishlist of Ready!

Many Agile and Scrum teams have adopted the practice of having a “Definition of Ready” as a way to explicitly define when a Story – or Backlog Item – is “Ready” for a team to take into a Sprint.  This often serves as an entrance gate for Stories and ideas to be proposed for Sprint Planning.  Some view this as a best practice but far more often this is an anti-pattern that often time creates the same impediments to a team’s agility that the organization was hoping to eliminate by adopting Agile or Scrum in the first place.  It is important to note that the “Definition of Ready” – or DoR – is technically not a part of Scrum.  The Scrum Guide – which was created and is maintained by the founders of Scrum – makes no mention of the DoR.

Typically, a team’s DoR will contain a list of criteria that a story has to meet before being eligible to be proposed by the Product Owner for Sprint Planning.  Some typical criteria might include (examples, not an exhaustive list):

  • A story needs to be estimated
  • Dependencies must be resolved
  • UI Wireframes have been created
  • A UI mockup has been created
  • All acceptance criteria have been documented
  • Test scenarios have been defined
  • A user workflow has been diagramed

Having these criteria are helpful, but they become a rigid list of entrance criteria for a sprint, they serve as a barrier to entry for new ideas.  This will often result in a number of unintended consequences:

Idea Lag

The promise of agility included the ability to rapidly respond to feedback and learning. For scrum teams one opportunity for short-term feedback is the end-of-sprint Review.  This is often the first opportunity for stakeholders outside of the Scrum team to see firsthand what the team has created; and an opportunity for the team and its Product Owner to get feedback and ideas from outside the team.  The hope is that we will learn or discover new opportunities that are even more valuable than the ones already identified in the Product Backlog.  If we get feedback, or identify an idea that is really important, we should be able to incorporate it into the team’s next sprint – which begins shortly after the review.  This is at the heart of the ‘act-inspect-adapt’ cycle.  However, the DoR often renders this impossible.  If an idea has to meet the DoR before a team can work on it, there simply isn’t time between the Review and Sprint Planning to do all the pre-work necessary to make it ‘ready’.  This means that the new idea cannot be worked on in the next sprint – it will have to wait at least the length of the Sprint.

Higher Risk, Uncertain Ideas are Deferred

Each sprint a Product Owner faces the additional burden of making sure that backlog items are ‘ready’ for the team’s next sprint. This is on top of an already full plate or collaborating and supporting the team’s current sprint work as well engaging and conferring with stakeholders as part of maintaining and managing the backlog. This creates pressure to get stories ‘ready’.  Generally, the more complex, uncertain or risky a story is, the more difficult it is to make ready.  The more familiarity we have with a story, the easier it is to make ready.  Since Product Owners run the risk of not having stories ‘ready’ in time for the next sprint, it is natural for them to gravitate towards stories that easier and faster to make ‘ready’.  This results in teams often working on the most ‘ready-able’ items, and not necessarily the most valuable items.  This also means that stories that have a high degree of uncertainty, unfamiliarity and risk, will end up being deferred to later sprints.  Deferring high-value, high-risk items is a poor product strategy resulting in increased risk over time.

Requirements and Analysis become Pre-work

The Definition of Ready for most teams is intended to ensure that we know ‘what needs to be implemented’ so that in Sprint Planning teams can focus on ‘how to implement it’. This means that the solution is pre-determined prior to Sprint Planning – essentially the requirements have been determined prior to the sprint.  A far better approach would be to have the team collaborate to explore different options of tackling a user or customer problem (or opportunity) that might be feasibly within the current sprint.  The analysis and discovery is now part of the story implementation – not something that is completed prior.  This also will allow the team to transform from a ‘Feature Factory’ to a team of ‘Problem Solvers’ and ‘Opportunity Enablers’.

A small shift in the way that a team uses a ‘Definition of Ready’ may significantly improve both their Agility and Delivery – is instead to tread the DoR as a ‘Wishlist of Read’ – or WoR.  Instead of criteria of ‘must haves’, the WoR represents criteria of Nice-to-Haves.

  • It would be nice to have a story estimated before sprint planning, but we could work on it even if it isn’t.
  • It would be nice to have dependencies identified before we start, but in Sprint Planning we have the right people in the room to deal with these so why not get started right there in sprint planning anyway.
  • It would be nice to have a user workflows and user diagrams before we start planning, but if we didn’t, we could still figure those things out during the sprint.
  • It would be nice to have all Acceptance Criteria documented, but it is far more important that these be understood the team. What better time to discuss these than in Sprint Planning when the entire team is present, the Story has been identified valuable enough to have the team work on it?

This idea of a ‘Wishlist-of-Ready’ rather than a strict ‘Definition of Ready’ minimizes the amount of pre-work and pre-effort that goes into the story and also maximizes the benefits of having your team collaborate to understand the story and optimize the solution.

Give it a try for your next sprint planning, and see how it makes a difference to communication and agility!

If you’re enjoying these Agile QuickTips by Giora Morein, make sure you never miss a valuable one by subscribing to our YouTube Channel. You can also follow me on Instagram or on Twitter, @GioraMorein

Agile QuickTip: Explicit Sprint Learning Goals

Explicit Sprint Learning Goals

On this edition of Agile Quick Tips, we’re going to be discussing how setting explicit sprint learning goals could help improve your team overall.

Agile teams or scrum teams will often set goals during sprint planning that help them to maximize value and optimize the product that sprint. But what if you thought beyond the product, and created goals and plans that went further?

One technique which I’ve found can really help is to set what I call ‘explicit learning goals.’

These could be anything, from learning something new about the customer or user, to understanding a piece of technology or software in greater detail. You could also aim to expand our knowledge that is soiled within the company, so that more team members can get value out of it.

The teams are then able to create opportunities to meet these goals, and plans to gain new knowledge or learning as part of the sprint. When this works, you’re not just optimizing the value of a specific product, or today’s sprint, but you’re also gaining knowledge and insight that helps team members to attain more in the future.

If you’re loving these Agile QuickTips, are you sure you’ve seen them all? From the idea of a popcorn sprint or a minute of fun,Agile QuickTip: A Minute of Fun to a learning-based shift in mindset for the week, all the back-episodes can be found by subscribing to our YouTube channel. You might also want to follow me on Instagram and on Twitter, @GioraMorein for more inspirational and practical advice on growing your Agile learning.

Agile QuickTip: Achievement Focused Daily Scrum

Achievement Focused Daily Scrum

If you’re feeling like your daily Scrum or Stand-up is getting less valuable, and losing some of its effectiveness, why not turn things around by changing the focus to achievements rather than activities?

Most Agile team’s Stand-ups or Scrums focus pretty heavily on activities. Questions asked in the daily Scrum include activity focused queries such as:

  • What did I work on yesterday or today?
  • What’s my plan for today or tomorrow?
  • What’s stopping me from doing these activities or tasks?

This can work well for some time, but it also can make teams quite task oriented or task focused, and stop team members thinking more broadly about what they are accomplishing and how to add value.

Sometimes it can be helpful to reorient your meetings around achievements instead of activities. Questions that you could ask during an achievement-oriented daily Scrum or Stand-up include:

  • What did I achieve yesterday or today?
  • What do I plan to achieve today or tomorrow?
  • What is likely to be the challenge in the way of achieving these goals?

Immediately, with this change in focus, teams are thinking about and discussing goals rather than activities. In turn, this allows each team member and the Scrum as a whole to deliver more value.

Our Agile QuickTips are simple, one-minute ideas that can revolutionize your existing Agile teams and implement quick changes that help them to be a whole lot more valuable. Make sure you haven’t missed any of our Agile QuickTips by browsing the back catalogue on our website or subscribing to our YouTube channel. You can also join the ThinkLouder community by following me on Instagram or on Twitter, @Giora Morein.

Agile QuickTip: The Open Meeting Parking Lot

The Open Meeting Parking Lot

Meetings getting off track? Have you thought about using the idea of an Open Meeting Parking Lot to make an entire meeting more focused?

Many Agile teams complain about meetings that get derailed. This can be anything from a daily Scrum that takes much longer than ideal because everyone has a lot of off-topic items to address, Sprint planning where team members keep getting into the weeds, or really any meeting that gets derailed and ends up far away from the items on the actual agenda for discussion.

One technique that really works is to create an Open Meeting Parking Lot.

Here’s how it works.

At any time during a meeting, when team members see that you are all going off topic or the meeting is in danger of being derailed, any participant can identify a topic to be discussed after the meeting, tagging it as a follow up item, and adding it to the ‘Parking Lot.’ This means it will be discussed ‘outside’ afterwards, rather than right now, during the meeting.

The trick to making this work is to ensure that the Parking Lot is visible for everyone. There are a number of ways to make sure everyone is on the same page and can see the Parking Lot items, such as an easel pad with sticky notes if you’re all there in person, or a shared document that everyone can see onscreen during a conference call.

Using one of these, everyone can see what the Parking Lot items are, everyone understands that they don’t have to be discussed in the meeting, and can join the discussion to address these afterwards.

Love this idea? Make sure you haven’t missed any of our Agile QuickTips by browsing the back catalogue on our website or subscribing to our YouTube channel. You can also join the ThinkLouder community by following me on Instagram or on Twitter, @GioraMorein.

Agile QuickTip: Implicit Task Estimates Instead of Explicit Ones

Implicit Task Estimates Instead of Explicit Ones by Giora Morein 

You’re about to learn how changing your task estimates from explicit to implicit could make all the difference to the productivity and experience of your Scrum teams.

Sprint planning is where most Scrum or Agile teams will take a story or a different backlog item and break it down into individual tasks or implementation activities. A lot of teams will then take these tasks and estimate the amount of time they will take in hours to help them with their planning.

If you’ve ever been part of these discussions, you know that it can often result in a contentious experience, where team members can struggle to agree or align their workload, and the whole thing can even end up being pretty painful.

One thing which can really help is to switch to implied or implicit estimates instead of explicit ones.

Here’s how it works.

Pick a task and break it down until none of the resulting parts are greater than a day or half a day. This way, you don’t have to assign estimates, because you know that no matter what, none of the tasks will be greater than a day or half a day.

A way to make this even more visual and valuable is to create burn-down charts which use the number of tasks left in a sprint instead of the hours. This way your sprint planning can be a lot more focused, an overall better experience and even result in a more effective sprint overall.

I really hope you enjoyed that Agile QuickTip, and will be giving it a chance during your next Sprint planning session. If you liked it, make sure to check out our other YouTube videos by subscribing to our channel, and head over to subscribe to our blog on You can also follow us on Twitter, @GioraMorein.

Agile QuickTip: Vegas-Style Retrospective

Vegas-Style Retrospective by Giora Morein

Vegas-style retrospective might really be the difference-maker in helping your team identify and exploit those improvement opportunities that can propel them through the stratosphere.

What happens in Vegas, stays in Vegas! This famous tag line might not immediately sound like it has much to do with agile learning or Scrum teams. However, I’ve found that implementing a Vegas-Style approach to your sprint retrospectives can make a real difference to how valuable they are. The idea is simple: What Happens in the Retrospective, Stays in the Retrospective!

The sprint retrospective might be the most important meeting that a Scrum team has. During this time, you and your team explores and analyses opportunities and improvements that the team can take advantage of in the next sprint.

In order for a retrospective to be effective, participants need to be open, transparent, honest and forthcoming.  This requires that participants feel safe to do so.  Much of what a ScrumMaster does during retrospectives is to create an environment that is safe enough to allow for this transparency.

Vegas-Style Retrospectives mean:

  • It’s a private meeting.
  • It’s a confidential meeting.
  • Only members of the scrum team are invited.
  • No meeting minutes. No notes. No recordings.
  • Activities and learnings are not shared.

This creates a safe environment where team members feel able to truly open up about how they feel, and their ideas for moving forward. This not only helps explores more improvement opportunities but will typically help bond team members closer together.

If you love these Agile QuickTips, make sure to subscribe to my blog at so that you never miss an episode. Take a look over our library of QuickTips to make sure you’re up to date. You’ll also want to join our online communities on social media, from Facebook and Twitter, to LinkedIn and YouTube. We’d love to see you there!

Agile QuickTip: Using a Shared Daily Goal to make Your Sprint more Valuable

Using a Shared Daily Goal to make Your Sprint more Valuable

The idea of a ‘Shared Daily Goal’ is really simple, and by using this tactic at the end of every scrum, you might see a huge impact on how valuable your daily scrum meetings are.

The daily scrum or daily stand-up is all about maximizing transparency and alignment for your entire agile team.

At this meeting, the entire team gets together and explores the progress and challenges of previous 24 hours and these impacts the collective plans for the next 24 hours. They can use this time to share progress, to explore challenges, and to bring into the light unexpected issues which have come up. For many Scrum teams, this results in the stand-up becoming very activity-focused. What is the progress that’s happened on specific tasks, and what activities will be happening in the next 24 hours?

One idea which can make your teams a lot more effective and aligned, is using a shared goal of the day.

At the end of each scrum, help the team define a collective goal for day – a major achievement that they are working towards.  This is the goal that as a team is going to focus on over the next 24 hours.

This technique can provide a greater sense of purpose and alignment, not only around the activities and tasks that each team member has, but also for advancing the overarching goals of the sprint as a whole.

Loving our Agile QuickTips by Giora Morein? Fantastic! Make sure you never miss an episode by subscribing to our blog at You’ll also love our curated Instagram content, our accessible and valuable YouTube channel, and our active Twitter account, so make sure to get following!