Agile Quicktip: Use Defect Thresholds to Help Product Quality

/0 Comments/in /by

Use Defect Thresholds to Help Product Quality

Most scrum teams have backlogs that contain more than just user stories and new product features. Oftentimes, they contain bugs and defects that have been reported by customers or users or even by the team itself. These aren’t always handled right away.

This isn’t necessarily a bad thing, as perhaps none of these bugs or defects are considered high priority or need fixing immediately. However, once there are a large amount of these in the backlog it can make your product seem sloppy or bug-ridden – no single bug may be a priority, but collectively the probably should be.

Placing a maximum threshold on the number of bugs or defects that a backlog can contain before triggering them being prioritized for the next sprint.  This sets a minimum quality standard, and gives a consistent approach to handling issues that come up with the product.

You could apply the same principle to larger programs that contain multiple backlogs.

Let’s say you set the threshold to five, or eight items. Once that threshold has been reached collectively across all backlogs, this sends a signal to teams that they have to prioritize handling those defects for the next sprint. With this process in place, teams will never see a proliferation of defects and you always make sure you have a quality and stable product.

I hope that Agile Quicktip was valuable for you and your teams. Let me know what number of items you choose for your own defect threshold in the comments and also how it works for you. Don’t forget to check out the rest of the series, and make sure to stop by Thinklouder.com where you can learn more about how our training and coaching offerings can help you and your team.

Agile QuickTip: Using Multiple Choice Estimates

/0 Comments/in /by

Agile QuickTip: Using Multiple Choice Estimates

If you ever find that estimating tasks during sprint planning is painful and argumentative then multiple choice estimates might really help with your team’s planning.

Most scrum teams follow a similar path during sprint planning. Team members will break user stories or backlog items down into individual implementation tasks or sub-tasks. Often, they will estimate these tasks in hours to get more detail into how long they they might take to complete. Often this will result in arguments amongst team members causing planning meetings to devolve into something far more contentious and painful than we had hoped.

A better alternative might be to use multiple choice options when estimating these tasks. For example, a task can be categorized as:

  1. A) Less than a day
    B) Less than 4 hours
    C) Less than 2 hours

In this way, each task only has 3 estimation options A, B or C.

Top tip: If a task is greater than a day, then have that team break it down into a smaller task, and then use multiple choice options to estimate the smaller task as ‘less than a day’, ‘less than 4 hours’ or ‘less than 2 hours’.

By applying this multiple choice estimation consistently at all your sprint planning meetings, estimation begins to happen quickly, reducing the amount of arguments while retaining the same level of accuracy.

I hope you enjoyed this Agile QuickTip, and I look forward to hearing how it worked in practice when you implemented it in your next sprint planning. Be sure to check out the rest of the series, and leave a comment or send me a message to let me know if there’s anything you’d like to see next. You can also head to Thinklouder.com to see how our training and coaching offerings can help both you, and your team.