The First Scrum Sprint is Going to Suck

If you’re new to Scrum then we need to get something out of the way. Your first sprint in scrum is going to suck. That’s the bad news, the good news is that your probably switching to Scrum because whatever your doing right now also sucks so you won’t be any worse off.

So if Scrum is so awesome and solves so many problems why will my first sprint suck? Well, you see Scrum doesn’t actually solve your problems for you, it exposes the problems that were already there so you can fix them.

Let’s use estimates as an example, if you’re not already estimating your workload before you commit to it then you might as well give up before you start, you’re almost guaranteed to bite off more than you can chew. This problem gets even worse if you do estimate your work items far ahead of time when new requirements or changes can still happen. That simple change you guessed would only take 4 hours has now become a major undertaking and you committed yourself to completing it in this sprint. The answer here is obvious, create your estimates during the sprint planning meeting so you never commit with an outdated estimate. This is exactly the kind of thing we might have overlooked and continued doing were it not for a small failure during a sprint.

That small failure is the real reason why sprints are so important. Failing a release is a Big Deal and nobody wants to be invited to that party but failing a short sprint (while not fun) is not the end of the world. Fail a sprint, learn a lesson, improve and make the next sprint better. With continuous improvement you may find that you'll be making up for lost time towards the end of the release anyways.

*Bonus, you can take this experience into this next release as well.

Bottom line: Nobody likes failing a sprint, but it’s an important part of Scrum and in the end we should try to avoid assigning sprint success or failure with a value like "Good" or "Bad". Each sprint is there to teach us something, either a sprint is succesful and it confirms a strategy that works or we fail the sprint and it highlights something that needs to be changed.

Try to avoid it but failing your first sprint (or first couple sprints) will give you some important clues as to how Scrum will fit your team over the long haul. More importantly, keeping your development cycles in sprints keeps your failures limited to a small timeframe of the overall project, thus giving you some room to experiment.

Stakeholders and Feedback in the Scrum Community

I feel like stakeholders don’t always get the attention they deserve from the Scrum community. You hear all kinds of things about planning sprints, creating and managing stories, tracking the burndown and a whole host of other things important to Scrum but you don’t really find too much in the way of getting feedback from your stakeholders in the community.

Let’s fix that shall we?

Stakeholders are essentially any person or group of people who have an interest in your product that aren’t directly involved with its creation. Basically, anyone who isn’t a product owner, scrum master or team member is a stakeholder in your product and potentially a useful source for feedback.

This means that at the very least, your product owner should be actively engaged with these folks to obtain good feedback for the product backlog going forward. Start by getting in touch with these people

• Customers (no brainer)
• End-users (might be different than your customers)
• Support
• Sales
• The Scrum Team

The first two fall into the “Duh” category so we won’t cover them too in-depth but the remaining three are sometimes ignored despite the fact that they bring a unique perspective to the product backlog. Let’s look at support first

Support:

Your Support team knows your product better than anyone (or at least they should), they know where all the performance problems are, the annoying behaviors, the most common errors and most importantly the things that your customers complain about but don’t bother to add to the backlog themselves. They’re also going to play an important part in the level of service that you can offer for your product, for instance you may see support put through a backlog item describing better error messages or logging in your application. While that type of request might not impact day-to-day usage of your software, it will make the level of service that support can provide that much better. Don’t forget to talk to your support team for feedback.

Sales:

This one will be either more or less dependent based on how you sell your software but keep in mind that Sales spends their entire day talking to people who are considering the use of your product. Because of this, Sales is likely going to be the first place you’ll find problems that you can innovate an answer for.

The Scrum Team:

A lot of people forget that the Scrum team is a major stakeholder for the project. And their feedback will likely be an order of magnitude more removed from the end-user experience than any other stakeholders it’s still important. Look for backlog items such as “Refactor X”, “Rewrite Y”, “Consolidate Z classes”, “Simplify U API”. While these things may not directly affect your customer’s experience they do tend to affect either the stability of the final software or the speed at which you can add new features.

Bottom line, feedback should be a cornerstone of your product. Your product owner should be consistently contacting your customer base, support team and sales to find more feedback or to better understand the needs of their stakeholders. Once you know what needs to happen, the rest is just the mechanics of Scrum as we all know it.

Breaking Down the Scrum Product Backlog

You'll hear me mention this a lot because I don't think it's given enough credence elsewhere:

The Product Backlog is the backbone of implementing Scrum successfully. Properly sizing the backlog items, creating good estimates, prioritization, and creating a definition of done all play into the product backlog and having all of these will make your life easier in a number of different ways.

So what goes into a successful product backlog? It's going to be the work that directly affects the final product and only the work that directly affects the product backlog. This means new features, bug fixes, slight tweaks to the interface and technical debt. All of these things are (usually) treated generically as simply "Product Backlog Items" (they're also sometimes called User Stories but that's another post).

So let's create a backlog item. We'll start by writing up an idea of what we want in the application:

It doesn't need really need to be much at this point, really just a name to stimulate conversation about what it will look like when it's implemented.

Now at this point, we need to know if this backlog item is important. This is where your Product Owner will come into play, he'll decide if this should be at the top of the backlog or near the bottom or somewhere in-between. In short we need to know the priority of these backlog items.

Ideally at this point the product owner would also give us a detailed description of what this will look like when it's implemented but they may need some guidance or feedback from the development team to know what to define.

Now you need an estimate and this is probably the most important part of the backlog. Good estimates allow you to commit to just the work that you can get done in a sprint and very often over-committing is a great way to fail your first few sprints. While I can't guarantee that you'll do this right when you first start estimating I can say that padding your estimates is most definitely something you'll want to avoid. Here's a couple things to keep in mind when estimating:

• If a work item seems too big to estimate accurately, break it up into smaller work items. You can attack it piecemeal from there and you'll also get the added bonus of implementing a backlog item over the course of multiple sprints if need be.
• Each backlog should be as independent from the others as possible. Try to avoid creating dependent backlog items as this fuzzies up the straightforward approach we're going for and adds a whole other layer of complexity that doesn't need to be there. If you absolutely need to, make the sequencing of your work items part of the priority system. The fewer moving parts you have the better.
• Your estimates have nothing to do with actual time. This is important, your team may estimate a sprint's worth of backlog items at 1000 hours and then finish early (or not finish, that's another article). That's okay, simply plan more work for the next sprint. What's more, a 3 day feature may take a new developer 5 days to finish or an experienced developer 2 days, that's okay too. Accurately estimating the backlog has more to do with how much work can fit into a sprint than it does making certain that our estimates are accurate. (Remind me to write about estimating in story points soon)
• Don't estimate low priority backlog items. Developer time is precious and while we might get to the bottom of the backlog someday for right now we're strictly concerned the work that might make it into the next sprint. Start estimating from the top and make your way down until you're comfortable that you have enough to plan the next sprint. Descriptions may change for lower priority items or new higher priority items may be added before the next sprint, don't worry about it for right now.

So that's really all we need in a product backlog item. Build your backlog with that info and you've got a great start to your first sprint. Next on the docket: Sizing your backlog items and estimating.

Diving into Scrum - Intro to Scrum Methodology

A large part of what I do every day involves working with software development teams that are generally new to Scrum and one of the tendencies I've observed is that Project Managers who are converting to a Scrum Master role lean towards over-complicating the whole thing before they even start.

Here's what I mean:

Imagine that you're not only new to Scrum, but new to Agile altogether and you've just received the directive that everything you've been doing up until now is wrong and we're adopting this new methodology wholesale in about 2 weeks.

You'd probably do what I did when I first got thrown into the deep end, you'd buy a few books, search the internet, maybe read through a few Scrum forums. The problem here being that you might come back with this idea that Scrum is extremely complicated and therefore difficult to implement. After all, you have to figure out what a user story is, understand story points, come up with a scheme for creating estimates, figure out all the intricacies in extreme programming, etc. etc. etc.

Let's step back for a moment and figure out the core pieces and then we can add in the complexity as we need it.

So what needs to be here?

• Well we're gonna need a sprint which is a short timebox, we do work within the duration of the sprint. For this to work correctly, we need two meetings for each sprint. One for Sprint Planning and one for the a Retrospective on the Sprint.
• We'll also need work to do, this will be the product backlog which is a list of things we can accomplish in a sprint.
• Someone needs to figure out which work from the product backlog gets done first, that will be our product owner who represents our customers.
• We also need to figure out how much work from the product backlog can go into a sprint so the backlog will need to be estimated at an item level.
• Somebody needs to do the work and create the estimates so we'll need a development team. Just to keep things properly branded we'll name this the Scrum team.
• Lastly we need someone who knows all the Scrum stuff. Branding is still important so we'll call him the Scrum Master.
• We need communication. We need the developers talking to each other so we'll set aside time for a very short conversation each day for the developers to touch base with each other. This usually involves the team standing up for a few minutes to discuss the day so we'll call it the Daily Standup.
• We also want to keep things transparent so everyone knows how the sprint is going. We'll allow anyone to listen in on the aforementioned daily conversation and also see the total work remaining per day in a chart. Since this chart burns down to zero work remaining over a time scale we'll call it a burndown chart.

So to break it down even further, we need:

• 3 roles: The Product Owner, The Scrum Team and the Scrum Master
• 3 meetings: Sprint planning, the Daily Standup and and the Sprint Retrospective
• 3 Artifacts: The Product backlog, the Sprint backlog and the burndown chart.

There's still some small bits and pieces missing but we've covered the base needs. Do all of these things and you're already doing Scrum, the rest will be filled in as you need it.

Scrum Blog Part 1: The "Scrum-ening"

Let's start with a basic introduction, my name is Sean McHugh aka the lead trainer at Axosoft. Since we make Agile / Scrum software here at Axosoft I tend to spend most of my time either working with succesful Scrum and/or Agile teams who are adopting a software solution or teams just adopting Scrum and Agile looking for a little bit of guidance. You may hear me mention OnTime every now and then (our flagship product) but I'll try to keep that to a minimum and just focus on Scrum as a whole.

What is going to make this blog a little different (and therefore worth your time) is the unique angle I approach Scrum from. I'm a certified Scrum Master and I have a good amount of experience helping teams implement Scrum and Scrum solutions I do not however work within a Scrum team. That means that I have the opportunity to see Scrum applied in all kinds of different environments and encounter a wide array of problems.

Because of my perspective on Scrum, you may find yourself occasionally at odds with the things I'm saying and that's actually a good thing. Jump into the comments, I love interacting with the Scrum and Agile community as a whole and I don't doubt that I'll end up learning just as much from you as you will from me.