Category Archives: Agile

3 ways to have a very agile Thanksgiving

As we head rapidly into the holiday season, taking vacation to celebrate with family and friends is bound to occur. For most, it is a time to relax and reflect on what to be thankful for, accompanied by turkey (or tofurkey for the meat-conscious) and cranberry sauce. For others, it can be a hectic time of delegating responsibility and tying up loose ends. Not so for this product owner! The following are 3 golden rules I follow before vacationing to keep the holidays happy and the hectic at bay.

#1 – Give someone the executive power!

Since the product owner makes the decisions, it is important to appoint someone else to make all of these choices. I usually pick someone who has a similar mindset when it comes to the product and prioritizing customer issues. That way, even if I don’t make the decisions, the outcomes are usually the way I would have wanted them.

#2 – Plan ahead, but don’t plan too much.

One of the luxuries of being a Scrum product owner, is that Scrum is a system that adapts well to change. If the unexpected happens (as it frequently does), having well-defined stories, a prioritized backlog, and someone with the decision-making power, goes a long way. Rather than plan for every possibility (because we all know that polar bear is going to destroy the server room), Continue reading 3 ways to have a very agile Thanksgiving

Agile Development: 5 Lessons Learned

Working in software development can be challenging and tricky without the right plan in place, especially without a plan that caters to your employees’ work styles. Here at SoftArtisans our development team follows the agile dogma and we’ve discovered several lessons along the way. Wondering if agile development is right for your team? See below for 5 things to keep in mind when implementing this work style.

1. You absolutely need backup from higher-ups.

Too often I have seen or heard of departments that were “going agile,” but management was not behind them. No matter how enthusiastic about it the developers were, their plans were ruined every time management expected something to be “like it used to.” Managers who don’t give things time to adjust create developers who don’t give things time to adjust, and then everything is doomed to fail.

2. Retros are vital.

One important thing about agile is that you can change things quickly when you need to. This applies to the direction the software is taking, but it also applies to the processes and mindsets of team members. This is what retrospectives are for. A good team will be able to be honest about what’s working and what isn’t and subsequently make changes for future sprints.
This whole process is much easier when…

3. Retros don’t include higher-ups.

Management usually wants to know what’s going on, and that’s great, but retros are not the place for it. Continue reading Agile Development: 5 Lessons Learned

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.