Archive for category: Blog

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 ThinkLouder.com to learn more about coaching and training offerings. For a daily dose of Agile inspiration, follow me on Instagram and Twitter @GioraMorein.

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.

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.

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