Darryl Booth

A Bug's Life

Decade Software Company makes big investments in testing prior to each release.

However, when a bug is uncovered in EnvisionConnect, I'm often asked by clients and staff to predict when that bug will be fixed.

I'm please to say that bugs are addressed very rapidly and with good predictability.

Below is a countdown of how a long a documented bug can live in EnvisionConnect.

Bugs, Critical Bugs, Normal Releases, and Emergency Fixes

Our developers work in 30-work-day sprints.

All known bugs on the first day of a sprint will be fixed by the end of that sprint.

Therefore, a non-critical bug can live between 30 and 60 days. In the worst case (bug discovered on the first day of a new sprint) it lives 60 work days. In the best case (bug discovered on the day before a new sprint) it lives 30 work days.

Obviously, it’s in our interest to document bugs as soon as possible.

A truly critical defect that impacts data integrity or prevents basic operations may be escalated for an emergency release.

A body of work (e.g., bug fixes) may be released to the user community earlier if the Product Owner (me in this case) prioritizes a mid-sprint release. This is not the norm.

Our normal release schedule is every 30 (business) days.

My Planning Hangover

For some reason, our planning activities for September washed over me this week like a tidal wave. You know that feeling when you know you need a breath, but there's another wave coming... so you'd better just hold on?

In one (short) week, we held Sprint Reviews, Sprint Retrospectives, and Sprint Planning meetings for three Scrum teams.

For the Product Owner, there's a lot of pressure to set the right priorities for the coming Sprint and to respond positively to the wrap-up of the just-completed Sprint.

Planning

Setting the right priorities means locking-in the efforts of three teams for the coming month (Sprint).

We definitely wanted to optimize our efforts in favor of our Annual User Conference. But to do so meant, navigating those murky waters where somebody else's interests were deferred.

Reviewing

I also learned this month about the purpose and implications of the Sprint Goal, a theme for the Sprint that allows the self-organizing and self-managing teams to align their day-to-day decisions without having to go to the Product Owner (or anybody else) for guidance.

I learned that instead of counting off the completed tasks during the Sprint Review meeting, the Product Owner needs to focus on the Sprint Goal and appreciate the extent to which the team rallied around that goal. Said another way, Sprint results may not appear exactly the way the Product Owner envisioned them a month earlier, but the goal or theme was reflected in everybody's actions and choices.

This is what happened. And for that I'm thankful.

Two Aspirin Later...

I think we emerged from this week without too much damage... with credit to the individual teams who ran with the priorities to make it work. Thanks guys!