The Daily Scrum Stand-up is Not a Meeting

One of the bigger complaints that you'll hear from Scrum Teams is that the daily scrum stand-up meetings are a chore. Upon further investigation you'll probably find a few commonalities.

Problem: The Daily Standup is a meeting

What do you call it when a bunch of people leave their desks to gather in a room to talk about something? It's not a stand-up (even if you're all standing), that's a meeting and it typically involves a lot of waiting for everybody to get there.

Solution: The Daily Standup is not a meeting

The entire team should fit into a single room (team size is another post). The Scrum master walks in the room (preferably at a known time) asks everyone to standup, we go around the room chatting about progress and problems and everyone gets back to work within 10-15 minutes unless something really interesting comes up. If an important stake-holder, Product Owner or anyone other than a team-member isn't there then they'll miss it.

Problem: The Daily Standup kills productivity

Imagine you're changing the oil in your car, you're wedged underneath the engine, elbow deep in the bowels of the vehicle just getting ready to pull out the oil filter (try to imagine if you've never actually done this before). Now imagine you have to drop everything, walk away from the car altogether to tell everyone about your progress on the oil change. Now you get to ease yourself back under the car, wedge your arm back up to the oil filter and start over again. If this were a daily thing then I'd start to get annoyed as well.

Solution: The Daily Standup happens quickly and early

Ideally the standup should happen first thing in the morning and before anyone starts in on their tasks for the day. In practice this doesn't always work since developers may come in at different times. Try to make the standup as early as possible before any serious work gets started.

Problem: Nobody pays attention at the Daily Standup

We're all here, doing the daily standup, each team member is taking turns telling everybody the details of what he did yesterday. Twenty minutes later, pretty much everyone has their phones out and not a soul is paying attention. We've now lost essentially 1/24 of a workday to an essentially useless Scrum Excercise

Solution: The daily standup is quick and/or interesting

"I fixed that date/time conversion bug yesterday, and I was gonna grab that sorting speed task today." "Ran into an issue with the search sproc yesterday, it was only returning a max of 400 results, got that sorted out and I'll be finishing up the search task for the user admin page today." Now imagine that happening for every team member on a 7 person team. The standup goes pretty quick doesn't it? The only time the meeting should go long is if somebody has a very interesting problem at which point the developers may spend some time discussing it. The standup should be either very short or very interesting but not boring. If it is boring, it's your fault (as the Scrum Master) for not educating the team in how to use this time.

Bottom Line: The daily stand-up is a major part of building a great Scrum team provided you don't screw it up by turning it into another corporate event. The stand-up centers around the Scrum team and nothing else. It's small amount of time (emphasis on the small) for the Scrum team to center in on their progress, goals and issues that are important to them. Anything else you do during the stand-up amounts to overhead.

What does the Scrum Master do all day?

The Scrum Master doesn't plan the release, that's done by the Product Owner and the Scrum team.

He doesn't manage the developers as the Scrum team is self-organizing.

He's not even the guy that gets his neck wrung if the end result sucks or doesn't come together (that's the product owner).

If the product owner is the head that makes the decisions and the Scrum team is the arms and legs that do the work then the Scrum Master is the ooey gooey insides that hold everything together.

So who is the Scrum Master and what exactly does he do all day?

Simply put, the Scrum Master is the guy that manages the Scrum part of development. That means our Scrum will probably have at least these things on his plate:

• Facilitating the daily standup (but not participating)
• Helping the team maintain the burndown chart
• Setting up any retrospectives, sprint reviews or sprint planning sessions
• Shielding the team from interruptions during the sprint
• Removing obstacles from the team (that they can't remove themselves)
• Guiding the Product Owner in his/her role
• Encouraging collaboration between the Scrum team and the Product Owner

You'll notice a common theme here. Essentially anything here that ties back to Scrum is directly tied to the Scrum Master or the Scrum Master will provide guidance. The point here is that the Scrum team will not overly concern themselves with Scrum and will mostly focus on the job of software development and the Product Owner likewise will focus on the stakeholders and business needs so they'll lean on the Scrum master to guide them in what's needed for the next iteration.

If this sounds like a full time job, that's because it is. The responsibility of the Scrum master is to make certain that Scrum doesn't get in the way of development or customer feedback which will take all of their time. That being said, not every Scrum Master is "just" the Scrum Master. Some teams may choose to elect a developer or tester to become the Scrum Master for the team, this shouldn't be considered the norm but it does occasionally happen so don't feel bad if you discover after your first couple sprints that your Scrum Master just doesn't have enough to keep him busy. Here might be some reasons why that is:

• Your product owner knows his customer inside and out and is always there for the development team without guidance from the Scrum Master.
• Your Development team has such a healthy communication culture that a daily standup is redundant and adds to the overall process overhead.
• The burndown chart and other artifacts are maintained automatically or otherwise incur no overhead on the development team.
• The team operates free of distractions and can clear all obstructions on their own with minimal overhead.

If these don't describe your team (or even if they do), separate out a Scrum Master for the team for at least one sprint before deciding one way or another how the Scrum Master will fit into your next sprint.

What's the Deal with Story Points when Estimating?

About a year ago, a buddy of mine asked me to help him install a car stereo he just bought and I readily agreed provided the beer was provided and my wife would let me out to play for the weekend. We sat down to figure out everything that needed to be done, took into account our expertise (I'm handy with a multi-meter and graphing calculator and my buddy has spent some time working on his car before), so we felt like we were over-budgeting when we said we could get it done in a weekend. Should be plenty of time.

Three weekends (plus a few weekdays), a very angry wife and a disheveled garage later we finally put the faceplate back on, plugged the battery back in, powered up the fruits of our labor and it was good. The problem wasn't that we couldn't do it or that we didn't have the resources or even that we didn't have the time. The problem was actually very simple, we hadn't done it before so of course we couldn't estimate our time correctly.

Chances are that you have a story that is at least a little similar to this. I want you to stop and think about that the next time your sitting down with a developer to discuss the number of hours they'll need to fix a bug that they just learned about 10 minutes ago.

See where I'm going with this?

Force an estimate out of a developer with a definite value and you're going to get one of two things:

• A thoroughly underestimated work item


• A thoroughly padded estimate

Neither of which is useful in the slightest when it comes to planning a successful sprint. Things get even worse when you consider that a bug might take a senior developer 2 hours to fix whereas that new intern may spend the entire day plugging away at it. We need a better way to estimate if we're going to have a successful sprint.

Let's loop things back in with that developer who's estimating.

Let's ask our developer to rate a bug from 1 - 10, 1 being "Easy" and 10 being "uninstall realplayer for good this time". That's the kind of thing that's hard to pad an estimate for since a developer who rates a bug at an 8 will probably take the same amount of time for something else rated at 8 later on. More importantly this gives us an average that we can actually normalize over a team while developerA may take 10 hours on an 8 Story point work item (on average) and developerB may take twice that long (on average) by averaging things out we're able to come up with a reasonable workload for the team over the duration of a sprint without stressing about dev-hours.

So we've got the basic concept down, hours are inaccurate and create false expectations which lead to even more inaccurate estimates which in turn leads to ulcers for everyone involved. Story points offer us an abstraction layer but the way we've been talking about still has some problems.

What happens when we get a work item that rates higher than the last 10 we implemented? We need to remove the upper limit from the scale and it'd also be nice to have an increment so we're spending time arguing among the team if an item is a 7 or 8. So story point estimates should be open ended (within reason, if something is too big then break it down to create smaller work items to plan with). We should also increment story point estimates, which is most commonly done in fibonacci numbers. This means that I can estimate a work item as 1, 2, 3, 5, 8, 13, 21... story points. The bigger an item is, the less accurate the scale so we move in bigger increments.

We now have a scale to plan with, we planned 100 Story points worth of work last sprint and failed miserably. We finished enough work items to total 80 story points so we'll plan that for the next sprint.

Each team will have a different scale of story points, teamA may estimate a work item at 21 story points and teamB may estimate at 13. TeamB isn't faster, they just think of story points differently. On the flip side, Team A may finish 1000 story points worth of work in a sprint and team B finishes 300, once again, team A isn't faster so much as they simply tend towards larger estimates. Focus on having the team estimate and commit to their own work since an estimate means next to nothing outside of the team and coach the team to base what they commit to in a sprint off of past performance (if you don't have any info on past performance then your first sprint will suck, but that's okay ).

And that's it, remove hours from the discussion when estimating and planning a sprint, focus on complexity and past performance and the team when planning a sprint and you're good to go.

Do you have to use story points to plan a successful sprint? Heck no, plenty of Scrum teams estimate in hours and have great success, in fact, check out THIS article our CEO at Axosoft wrote on Scrum. Among other things he lays out a way to estimate without story points and it works great. The point here isn't to tell you the right way or wrong way to do thing (as if such a thing could exist for a development team), the goal is to put another tool in your hands to fix problems that might arise.

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.