Tag Archives: scrum

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

Scrumming in Trello as a Product Owner

This morning I signed into my Trello account and I was greeted by Taco, the mysterious Husky mascot:

He told me to go to my profile for a special prize. Now I am the proud owner of a…that’s right, you guessed it: Blue Starfish Trophy.

Husky and Blue Starfish aside, it’s hard to imagine my life without Trello to keep track of practically everything that I do at work.

When I first saw the online tool, I saw the potential for personal use with my costuming hobby, as a way to keep track of elements that needed to be completed and as a way to share my progress with other members of my costuming circle.

Continue reading Scrumming in Trello as a Product Owner

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.

Scrum Debates: Research as a Task

The concept of scrum can seem very simple in theory. As stories come in, the team analyzes them, and then story points them based on the complexity of the story. It couldn’t be simpler. But in practice, it is rarely this simple. The problem is that sometimes you won’t know just how complex a story is until after you’ve played around with it a bit. At my company, this is a problem we face almost every time we meet to story point backlog items.

Usually, a bit of uncertainty is fine. That’s the entire reason teams usually story point with a non-linear scale (one the popular scales being: 1,2,3,5,8,13,20,40,100). If a story could be anywhere from a 30 to a 40, then just give it a 40 (assuming we’re using the popular scale). Even if the story ends up closer the 30, there’s probably some other story that was more complex than its story point implied and it all generally averages out. But every now and then, there’s just too much uncertainty. A story might be anywhere from a 5 to a 50 depending on factors you won’t know until you’ve looked into it a bit and done some research. Continue reading Scrum Debates: Research as a Task

Scrum Debates: Story Pointing Bugs

Our company adopted scrum as our method for development over a year ago. And to this day, we’ve yet to get it entirely right. Over the months we’ve had to address issues ranging from “What do we do when critical issues come up?” to “Who should be a part of our daily scrum meeting?” to “What the hell is a story point anyway?” But one such problem that our Product owner recently brought up is, “Should we really be story pointing bugs?” And the answer, of course, is… well, actually, no one can really agree on an answer.

Well, let’s start out with why we all originally said yes. In any given sprint, our team will have to commit to some handful of stories and bugs off the top of the product backlog. If both the stories and bugs are story pointed to the same scale, then we have no problem deciding how much we can commit to this sprint given our previous velocities. And for a while, this worked fine.

But let’s look at this from the product owner’s point of view. Let’s say we’ve just released the next version of our product and now our product owner is looking over the backlog, trying to figure out how many sprints we’ll need to complete the required features (let’s say there are 10) we need for the next release. Each of these features gets defined as a story. For the sake of simplicity, let’s say they all have a story point value of 10, resulting in a total of 100 story points. In our past sprints, our velocity has averaged 20 story points. So our product owner can set the next release date for five sprints from now. Easy! Continue reading Scrum Debates: Story Pointing Bugs