Agile QuickTip: User Stories and Product Ideas Should be Born on Index Cards

How Do You Capture Your User Stories and Product Ideas? Try Index Cards

Here’s an out of the box idea that at first glance might seem counter-intuitive. I believe that user stories and product ideas should be born on index cards, rather than immediately logged electronically.

Most Agile or scrum teams will use some kind of electronic tool as a repository for their product backlog. This could be a JIRA, or Rally, or it might be something as simple as an Excel spreadsheet or Google Sheet that houses user stories. Sometimes, however, an electronic tool can serve as a barrier to creativity and collaboration, exactly what you need for brainstorming and idea generation.

A better way to capture these ideas is by using an index card or a sticky note. Think about how ideas are generated. The product owner will be talking to users, engaging with customers, discussing with stakeholders or even informally chatting with their own team members.  Pausing conversations to type notes into a computer or mobile phone would really slow those conversations down. Capturing these ideas on an index cards has a few key benefits:

  1. It makes the whole process a lot more tactile, supporting different kinds of learning and collaboration.
  2. It encourages others to participate at these vital early stages where creative sparks can fly more easily. Everyone can contribute ideas on their own post-its.
  3. It allows the Product Owner to take leadership over which ideas are best and should be included in the repository. Index cards can be moved, groups, prioritized, etc.
  4. It streamlines the eventual list of ideas and user stories to the most essential and immediate. Not all the ideas should make it into the repository. Product Owners can filter the sticky notes or index cards they want to include.

Give it a try next time you’re with your team, and let me know in the comments if it makes a difference!

If you are enjoying these Agile QuickTips, don’t forget to subscribe to my YouTube channel, as well as check out the website to learn more about coaching and training offerings. For a daily dose of Agile inspiration, follow me on Instagram and Twitter @GioraMorein.

Agile QuickTip: Safety Checks to Kick Off Your Meetings

Safety Checks to Kick Off Your Meetings

We often assume that participants in teams feel comfortable being open, transparent and forthcoming in a way that will make meetings and interactions meaningful and valuable.  But what if this assumption is wrong? How would we know?  How might this affect a meeting, it’s participants and the meeting outcomes?

One simple technique that can be introduced when kicking off any meeting is the Meeting Safety Check.

At the start of a meeting, all you need to do, is ask participants to rate on a scale of zero to five what their level of comfort or safety is, in participating and sharing information during the meeting. You could have people hold up the corresponding number of fingers; or write a number on a post-it. If you’re concerned that team members won’t be honest about in their rating you could do this anonymously to help participants feel more comfortable sharing.

Based on the results of the Safety Check you then have three choices: continue with the meeting as planned, keeping an eye out for the team dynamics; address the safety concerns before the meeting begins; or cancel the meeting altogether until the safety concerns have been addressed. By introducing Safety Checks, not only do we make meeting safety a meeting pre-requisite priority, we also introduce a way to assess and evaluate when safety issues dealt with.  Meeting safety will likely lead to more engaged participants and better meeting outcomes.

I hope that this Agile QuickTip was enjoyable and valuable, and you can see yourself implementing it into your team meetings. Make sure to check our YoutTube channel to catch up on the ones you’ve missed! Don’t forget to head to to see our training and coaching offerings, and hit that follow button on Instagram, @GioraMorein, as well as on Twitter.

Agile QuickTip: Your Process Management Tool is not a Facilitation Tool

Process management tools are a common way to for a team to manage its work, it’s backlog, and its plans.  But these are repositories of information, they are not likely the best way to create this information.  Here’s an idea that might make work better.

Most agile scrum teams will use some kind of digital or electronic tool to help manage their team process. Maybe it’s Jira, or IBMs RTC, or Rally, or Microsoft’s own product. All of these tools have pros and cons, and are great process management tools, made to hold and manage a repository of information about your plan and your backlog. Regardless of which tool you choose, you need to remember that these are process management tools – not facilitation tools.

Just because these tools are the best place to store your information, does not mean that they are the best tool to facilitate the creation of this information. You need to find alternative ways to facilitate collaboration and communication to create this data – regardless where it ends up being stored.

Seek out tools that can help facilitate discussion, planning, solutioning etc.. Use more tactile tools if you can – like sticky notes or index cards.  If your team is virtual, us some kind of collaborative whiteboard or shared canvas – like MURAL.  You could even use more real-time data-capture tools – like Google Sheets or Office 365 that lets multiple people edit a shared document at the same time.  Using more facilitation-centric tools, your team can generate far more ideas; ensure that every voice is heard; avoid group-think;  and supports collective ownership of the outcome.  You’ll then need to then figure out the best way to extract this information and ‘import’ it into your process tool.  This will result in better information being captured and will even make your process management tool more useful, and far more valuable.

Skip the process management tool and pick up the sticky notes, and let me know how it turns out!

If you enjoyed that Agile Quicktip and found it valuable for your teams, make sure to check out the rest of the series. I would love to get your feedback, so please do leave a comment below, or send me a direct message. You can learn more about our training and coaching offerings , or follow me on Instagram, @gioramorein.

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.