Sprint Lengths and Long Releases

If you're not careful, the length of your sprints may become a one size fits all solution wherein you try to shoehorn every development effort into a 2 week iteration or some other length. I try to caution people from reaching this point for a number of reasons.

Certainly, having a shorter sprint size has it's advantages because the shorter time frame allows for more accurate planning, faster feedback and a bit faster pivoting for the team. There's another side to this as well though, before every sprint you have to have a sprint planning meeting. Ideally your developers will estimate (or reestimate) their work items right before the sprint. Before you plan the next sprint, you need to review the sprint and perform a retrospective. All of these things are good and should be done between each and every sprint, but they also mean time that the development team is spending away from more important things, like development.

And therein lies the conundrum. Traditionally you would try to reach some kind of happy medium for sprint length and that sprint would become the heartbeat of iterations for your software. Every 2 weeks, 3 weeks or 1 week you would finish the sprint and there would be a new potentially shippable iteration of the product. This is good, many teams will start doing this and will likely continue because it works great, but don't let it become a rigid law for your organization.

But here's a thought: no Scrum rules should overcome a thoughtful decision made by an intelligent person (which I'm assuming you are). Which is to say, we should protect the team from being overburdened by the Scrum Framework.

What if we were working on a long-term unannounced project? Perhaps it's a AAA game title or an entirely new product with a deep feature set. In either case, customer feedback isn't that useful since our customers don't even know the product exists. Moreover, for at least the first few sprints, the development team's focus will be more towards achieving a minimum viable product.

This doesn't mean that we throw Scrum out the window, in fact just the opposite. Sprints, retrospectives, planning and the product backlog become even more important. Since this specific article is about sprint length we'll start there.

If this is a new team working together for the first time, short sprints are probably best so that we can loop back in often for retrospectives, maybe a one week sprint or so (shorter or longer, it's up to you). Tuning a team to work together will make your life much easier on the long road to the release.

Once the team is comfortable working as a unit, those retrospectives (while useful) can be seen as overhead if they're done too often and since the product backlog primarily consists of Minimal Viable Product work at this stage, priorities are unlikely to shift too often. As we begin to settle in for a long release you can lengthen your sprints (every two weeks or every month). You'll still track your daily progress via the burndown chart and your daily standups, but will loop back in to finish the sprint less often.

Once you begin closing in on a release, feedback becomes important again, functional testing will provide new insights, tweaks on the original design are made, beta testing will finally allow for customer feedback, etc, etc...

Because of all the new feedback as we get closer to a final release, it can become important to shorten up the sprint length again to allow the team more room to change direction and priorities between sprints.

Using variable sprint lengths are probably not the norm and is usually reserved for longer development cycles with a minimum amount of customer feedback, but ultimately the sprint length is a tool for the Scrum Master to experiment with and use to the development team's advantage.

What are some of the things you've noticed about how sprint length affects your team?

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.