There’s a new generation of entrepreneurs that cares more than just about short term money grabs, an all too often desire from wall street investors. The value of a company is in the intermediate to long term, in creativity, experimenting, empowering, and innovating — and companies like Facebook, Apple, Google, Amazon are eating the rest of the industry’s lunch. Get ready, because Apple will be your new bank, and Google will be your new cell phone and internet provider. The legacy companies are dying off like the dinosaurs. IBM and Blackberry are on my radar as some of the next to go down in flames. Microsoft, while struggling, is adapting, so I think they will make a comeback if they continue to change course.

We are lucky enough to be in the business of helping companies compete in this very daunting marketplace. Give us a call if we can help you out.

Like this:

Ken Schwaber announced today that a new Scrum Guide is coming in the next couple of months. In my position as a Professional Scrum Trainer certified through Ken’s Scrum.org, I was aware of this earlier this year and I have to say… the Scrum nerd in me is excited! It’s so great to see that Scrum is evolving, because this is one reason many of the past methodologies and frameworks died out. It’s also very much in line with the “inspect and adapt” nature of Scrum, so it’s wonderful to see Scrum’s founders and shepherds leading by example.

I also want to drop another hint. There are some other interesting things happening in the Scrum world this summer that I cannot yet talk about. Subscribe to my blog to stay tuned!

Like this:

I often get and see questions on internet forums related to helping someone slice their User Stories or Product Backlog Items. This can be very difficult to do, because the slicing conversation really requires so much context around the parties/teams involved, the nature of the business domain, and the technical structure of the system under development. Due to this complexity, this is why I always recommend that Product Owners and Development teams do slicing together in Product Backlog Grooming sessions.

Another problem with trying to provide the needed context to give good advice is that most people work at organizations that have some sort of information security policy that would be violated by providing enough context.

The best route that I’ve seen is trying to come up with a fictional story/PBI/context that demonstrates the key challenge that you’re having without improperly offering too much confidential information.

I wrote a skit for a presentation I did at MileHighAgile 2011 that demonstrates a team doing Product Backlog Grooming for a User Story. In the skit, backlog grooming is covered pretty well, with the one exception that estimation was not covered in the skit. You can read the script of the skit here:

One of the aspects of the Bradley Bug Chart is that bugs like the one mentioned (i.e. non legacy bugs) end up on the Sprint Backlog. Because they end up on the sprint backlog, if one is using Story points and velocity, no story points are assigned and no velocity is gained from fixing bugs. This, once again, helps provide transparency on to the lack of progress that the team might be making due to bug fixing. The truth can be a hard pill to swallow, but the truth will also help set you free from these mistakes in the future.

The transparency should help all involved understand that there is something that needs improving, that is dragging down the team’s ability to produce new features and working software. I would argue that this is not a sprint killer. It is simply a fact of complex software development.

The real issue comes down to this: Scrum transparency is trying to tell your team something. What is it trying to tell your team? What is your team going to do about it?

Related Articles

Looking for Agile/Scrum/Kanban Coaching or Training? Contact us for more info. We have some good specials going on right now, but they won’t last long!

Finally, a Scrum certification course aimed at ALL members of the Scrum team! Developers, Testers, Business Analysts, Scrum Masters, Product Owners, etc. Feb 28th in the Denver Tech Center. More info and sign up here!

This post has been deprecated.

Essentially, if you look at the Bradley Bug Chart on the replacement post, any bug that ends up on the Product Backlog(Legacy Bug, “Not a Bug”, “New Feature”, or “Deferred Bug”, etc), should be assigned story points, and any bug that ends up on the Sprint Backlog should not be assigned story points.

[old deprecated article below –V]

First a definition.

Bug – Any behavior of the system that either violates an acceptance test, or is unacceptable system behavior that cannot practically be covered by an acceptance test(for example, aesthetics issues, or legacy bugs). Another way of saying this is any behavior that is inconsistent with previously well understood requirements and/or acceptance tests.

This definition is useful when deciding whether something is a bug or an enhancement.

So, I break bugs down into the following three categories and assign points as follows:

1) Legacy bugs
I define a “legacy bug” as any bug that was introduced prior to the team adopting Scrum. Those go on the backlog as user stories and are estimated in points and prioritized by the PO.

2) Scrum Era bugs
Any other “bug”, introduced since adopting Scrum, is fixed within one sprint of it’s discovery(this sprint or next) and no story points assigned, unless both the PO and dev team agree to defer the bug beyond that next sprint(Deferred bugs). If either the dev team or PO chose to have the bug fixed this sprint or next, then the bug appears as a task for the sprint, and is estimated in hours.

3) Deferred bugs
These go on the backlog and are estimated in Story Points and prioritized by the PO.

While this logic is somewhat complex, all other decent solutions to the “should I assign story points to bug fixes” are also fairly complex, and usually have much larger risks of bad effects.

Some subscribe to this theory that “bugs can’t be well estimated” theory. I don’t. Here’s why.

I encourage team members to take some time to investigate a bug, up to an hour to estimate a bug that appears to be nasty. This helps reduce estimation inaccuracies.

I encourage teams to then “inspect and adapt” on sizing bugs, just as they would for User Stories.

If the team still can’t be terribly accurate after a few iterations, then I would probably just encourage them to spend more time investigating nasty bugs to obtain a better estimate — this would be an extreme situation in my opinion(very low quality product). Note that they can only investigate for an estimate, the time is not meant to spend diagnosing or fixing the bug.

Some teams try to set aside a set amount of time each sprint for fixing bugs, and assign story points to that effort. I also don’t agree with that, as I feel it hinders transparency and makes it too easy for teams to sweep new bugs under the rug. “We’ll have time to fix this later in the bug fixing sprint or in the bug fixing time-box next sprint.”

Having said all of the above, while PO’s are certainly allowed to prioritize bugs into sprints, the dev team is also allowed to pick any bug it feels needs fixing (whether it be on the backlog or not), and bring that into the sprint as a task (they gain no story/velocity points for this, regardless of whether the bug was on the backlog or not). Only the dev team can decide how much product backlog to bring into a sprint, so if they decide to spend ~ 50% of their sprint bug fixing things not prioritized by the PO, so be it, but it will be visible because their velocity will be lower.

So, in short, Legacy and Deferred bugs can be fixed either:
a) When they are prioritized into the sprint because the PO perceives business value gained (story points added into velocity), OR
b) When they are brought into a sprint by the dev team because the dev team perceives value, and no story points are added into velocity as a result of fixing these bugs.

According to Mike Cohn’s User Stories Applied :
“…the developers will estimate how much work they’ll be able to do per iteration. We call this velocity…”

Further if you measure velocity in User Story Points, then each User Story must be
“…valuable to either a user or purchaser of a system” (also from Cohn’s book)

So, velocity is meant to be an estimate of a team’s iteration capacity to deliver User Stories that are of value to users and stakeholders outside of the dev team. I believe the above strategies that I describe do just that.

I could be wrong though, and I encourage others to let me know if they think I am!

About the author:Mr Bradley is an experienced Scrum Coach, Certified ScrumMaster, and Certified Professional ScrumMaster I. In addition to his Scrum credentials, Mr. Bradley is also a highly capable, full lifecycle experienced, software development team lead that prefers XP for good engineering practices. He is Sun Certified in Java, and has 13 years of experience in J2EE application development across all tiers. More recently he has also picked up some good C# experience as well. In his spare time, he enjoys driving his wife crazy by talking about Scrum, especially when he refers to his “honey do” list as his “personal backlog” and asks his wife to prioritize her requests. He lives in Denver, Colorado, and he is easily found on LinkedIn.