All posts by greg

Agile

Dealing with Bugs in Scrum

One of the big questions we had to answer for our Scrum development process whether or not to story point bugs. Development wanted to story point bugs to help with sprint planning. The Product Owner (me) didn’t want to story point bugs to maintain an accurate velocity. We experimented with a few approaches and settled on one that works well for us. In this post I’ll run through the issues and solutions we came up with.

Our Problems with Bugs in Scrum

Bugs pose a bit of a problem in Scrum because of how velocity and scheduling work. The measure of progress is the amount of value added to the product, and we use story points to estimate how much of that value we can fit into a release. This is tracked as “velocity.” For developers, velocity also acts as a benchmark for deciding how many stories to include in any given sprint.

This use of velocity is basic Agile practice and works pretty well for the most part. However, bugs are going to happen no matter how good your developers are. As a Product Owner, I evaluate the bugs that come in and decide if/when to fix them. From my point of view, the bugs are scheduled just like stories… the most important things get done first.

When we get into sprint planning, Development has to figure out how much to pull into the sprint, including both stories and bugs. This is a little tougher because bugs don’t have story points, so you have to “groom” each bug during sprint planning to get a sense of how much work it requires. Sprint planning gets much more painful when it also involves grooming. You might argue that there shouldn’t be enough bugs to make this a big problem, and I wouldn’t disagree. But we’re transitioning an existing project to use Scrum, so we have a number of bugs from the B.S. (before Scrum) times. Even for new projects, sometimes bad things happen to good people and you end up with more bugs then you’d like.

Development requested that we start story pointing bugs to make sprint planning a bit easier. There are a number of reasons why I strongly suggest you DON’T do that, but we’ll leave that for another day. So, short of story pointing bugs, how can we make dealing with bugs easier in Scrum?

A Possible Solution: Bug Points

We experimented with a few solutions and settled on using both Story Points and Bug Points. A Bug Point is a Story Point, but only gets used for bugs and does not get counted in the velocity. We use the same scale as Story Points and assign them during our normal grooming sessions. Really the only difference is that we put them in a different field in JIRA (our issue tracker). Development also keeps track of “total work” for sprints, which includes both stories and bugs. However, this metric is NEVER used outside of sprint planning. At no point will I (the product owner) ever look at that metric and say “Well, our velocity is 15, but really we’re doing 20 points of total work, so I bet we can squeeze in these extra stories for the next release.”

When it comes to sprint planning, the team gets together and works out what can fit into the next sprint. The bugs in the backlog are prioritized along with the stories because some bugs need to be fixed now and others can wait for a while. Since bugs are also pointed, the team can easily look at the backlog and determine how far they can get. They don’t have to reevaluate each bug as it comes up in the backlog; they’ve already done that work and can just keep rolling.

This works well for us because it’s easier to know what’s going to fit in the sprint. It also allows the team to have a somewhat more realistic view of how much they can fit in a particular sprint. Note that I said a particular sprint, not a release. Remember:  NEVER consider bug points during release planning! If the team has bugs in 4 straight sprints, then don’t have any they have a better idea of how much they can fit without any bugs to work on.

There are a number of other benefits. For one, you get a better sense of how much extra work you’re creating by letting bugs slip through the cracks when implementing a story. This helps to spot quality issues. If you’re constantly creating more bugs than value then you know something is wrong.

What’s Not So Good About This?

It’s very easy to fall into the trap of using bug points like story points outside of sprint planning. As I mentioned earlier, including bugs in your long term planning is a bad idea. Bug points are so similar to story points that it’ easy to forget that they AREN’T. Other than that, this seems like a pretty good solution to me.

It works for us, but how about you? I’d love to hear about how others are handling bugs in the backlog.

OfficeWriter

A1 to Column Index Calculator

When referencing a column with the ExcelApplication object, you can use either an A1 notation or a 0-based index. Code using the former is more human-readable, while the latter makes it easier to process multiple columns at once. It would be helpful to be able to quickly convert a column reference from one style to another.

Attached is the A1 Calculator, a simple Windows application that converts an A1-style column reference to a 0-based column index and vice versa. The application accepts input in either style. Current it supports the binary Excel format, which allows a maximum of 256 columns, from A to IV. It performs validation to ensure that the input is valid.

 

 

 

 

 

 

SSRS

SSRS: Improve Performance by Automating Report Caching Using Null Delivery Provider

If you’re familiar with subscriptions in SQL Server Reporting Services, you may have wondered what the “Null Delivery Provider” is for. While it may seem odd to deliver the reports to a black hole, it does come in handy from time to time. In this post, I’ll show you how the “Null Delivery Provider” can help you increase performance by automatically creating cached reports. The basic idea is to create a data-driven subscription to run the report with a number of different parameter values to build the cached copies. This is similar to creating Execution Snapshots, but in this case we can specify a number of different sets of parameters, where as Execution Snapshots allow only one set of parameters. The “Null Delivery Provider” allows you to do this without having to save the reports somewhere, taking up valuable disk space, or have them emailed to someone, taking up valuable sanity.

In case you’re not familiar with cached reports, SSRS lets you create copies (or “caches”) of a report after the data has been gathered, but before the report has actually been rendered. When a user runs the report, it’s rendered from the cached copy which already has all the data. This means the queries don’t have to be run every time the report is generated. If you’d like to read more about report caching, there are some good articles on MSDN.

This example uses the Product Line Sales SSRS 2005 sample report. Everything for this example still works the same in SSRS 2008. Continue reading SSRS: Improve Performance by Automating Report Caching Using Null Delivery Provider →