Tag: Product Owner

Categories
Agile Geeky/Programming

Agile: Tech Debt Sprint

In software development, the biggest thing you can do for the users of your product is deliver value. Adding business value is critical to maintaining a good product and keeping users happy. But there is another group you need to keep happy as well, and that is your development team.

Technical Debt (think of it like real money debt) is the extra WTF’s that add up in your codebase over time. You add a new feature, and take some shortcuts, you say “we will fix it later” but later never comes. You end up with untested (Unit Tests/Developer Tests) code and with “legacy code” that is hard to maintain. How do you get rid of all that? You have to pay down your debt, that is where Tech Debt Sprints come in.

Just like paying down regular debt or even how people keep regular debt, you usually have some. People have mortgages, or car loans, that they pay down. So in any app you end up having tech debt, but you need to keep paying it down instead of just adding more and more debt, because sooner later you’d have to declare technical bankruptcy, which is no good. (Close Shop? Rewrite? etc).

What I like to do is balance tech debt in two ways.

1. First, in every sprint, there should be a percentage of points dedicated to technical debt. 15-25% is a good number.

2. Second, every X sprints you should flip that percentage. So if you usually do 70% enhancements, 10% bugs, and 20% tech debt, every 4-6 sprints, you should flip it around: 70% tech debt, 10% bugs, and 20% enhancements. I might most later on the concept of another type of sprint, a “Hardening Sprint” where you dedicate 70% to just bugs to “harden” your app.

Now, you may have to negotiate with your Product Owner, which after a while they might get high on the drug that is enhancements and business value. Most reasonably Product Owners though, will realize that the code and developers need to pay down tech debt to make the overall application better and also make it easier to get future enhancements to market faster.

You may even get some stories that I like to call “Trifecta” stories. What are they? Well it is that “magical” story that satisfies three causes, Enhancement, Bugs, and Tech Debt. An example might be a crappy custom control that you’ve had in your app that you can replace with built in functionality or a better architected 3rd party control. Users will get the added functionality (enhancement), crazy bugs from your custom code are gone (bug fixes) and tons of crappy code is just dropped from the codebase (tech debt). Everybody is a winner!

I blogged previously on using User Voice to track your tech debt items at a higher level and have devs vote on them, it works somewhat, better than nothing. Usually stories come out of each “idea”. The bottom line though is to make sure you dedicate time and effort to paying down your technical debt. Far too often dev shops ignore this or always put it off till some mythical “later” that never comes. You need to just do it. It will make your code and app better, your devs happy, and keep things moving forward.

Categories
Agile

Agile: Priorities

Agile .. priorities…

what are they?

The product owner or people driving your features/bugs/issues of your scrum team need to set priorities of your stories. How do they do that? Simple:

5
4
3
2
1

Now here is where it gets crazy. People always ask: What is high? What is low. Stupid question.

1 is low. 5 is high. numbers just work out that way. I find it funny going into a project or team or whatever and they are like, it is priority 1!!!!! really? so 1 is higher than 5? What crazy math are you using? 5 is higher than 1. Always. Just do it.

Anyways, the product owner set’s the priority. 5, 4 – you pretty much always score/do first. 3/2, get to when you can, and 1, well, those are wishlist/nice to haves, and you get to whenever. They usually sit in the backlog forever.

What happens when you have multiple product owners or you do stories for multiple product owners? Well, they set the priorities of the stories. If there is someone above them, they might over rule. There might be a “steering” committee meeting or prioritization meeting to set priorities of all the stories in the backlog.

The team/scrum master shouldn’t be guessing on what to do, the priorities need to come from somewhere above or someone driving the project from a business perspective.

1,2,3,4,5

Lowest
Low
Medium
High
Highest

Whatever you choose, your stories need to have priorities, and they need to be set by the right person.

Categories
Agile

Agile: Backlog

The product backlog. Not a ton to say on this right now, but here are some thoughts.

  • The current sprint is not backlog
    Seem’s obvious. But the backlog is the backlog. The current is sprint is what you are focused on and working on.
  • The next sprint is backlog
    yes, the next sprint, on your board, is still backlog. It is somewhat solidified, but it is in flux until when you start the next sprint as your current sprint.
  • Your backlog should be semi-full
    having nothing in your backlog means.. well, you have no backlog, and that isn’t good. You should have enough stories for 1-2 sprints. Having no backlog is like living paycheck to paycheck.
  • You should prune old stories
    Older stories that have been just living in your backlog, should get pruned. Either they are higher priority and should get done, or they aren’t worth doing. They might resurface later as something but they shouldn’t be carried along for months/years if they aren’t important enough to do.
  • Priority matters
    The product owner should make sure they have the backlog prioritized. An backlog that isn’t prioritized is just a stack of cards.
  • Split Backlog into buckets
    I like to split backlog into buckets. Technical vs Product, maybe Features vs Bugs, some way to differentiate things.
  • Try to get as much as you can scored
    You might want to try to score as many stories in the backlog as you can so you are always ready. Of course there is a balance. You want a full backlog, you don’t want 5000 items, and you don’t want to take 3 days scoring things. Score enough so that if you do get ahead you can take stories from the backlog to work on. Try to avoid scoring outside of sprint planning sessions.

The backlog is one of the most important parts of your Agile process. Without a backlog you don’t have anything to focus on as you move forward through iterations. Try to think of it as a well, a well you don’t want to dry up, but you don’t want to overflow either.

My preference is to have a product backlog and technical backlog. That ensures that technical debt isn’t ignored, but separates concerns as far as features that you might want to implement.