Agile QuickTip: Add Expiration Dates to Your Backlog Items

/0 Comments/in /by

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

/0 Comments/in /by

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?

QuickTip

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 ThinkLouder.com 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!

/0 Comments/in /by

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