Tuesday, October 16, 2007
Scrum thoughts: Staggering sprint teams

When you have two or more sprint teams dedicated to a product, I think there's an opportunity to stagger their efforts in the following way. Let's track a user story through two sprints. In the first sprint, the prototyping sprint, design, UX, and development cooperate to put together a working proposal for a user story. At the sprint review, if possible, the whole user story will be complete, where design, UX, and implementation are all consistent.

This is very important, because one of weaknesses of the traditional waterfall method is that design, UX, and implementation must be consistent before the software is finished. Obviously, the implementation will be influenced by the design and wireframes, the wireframes will be influenced by what is visually possible on the page, the design will be influenced by the functionality required by the wireframes, the design will be influenced by what is hard or easy to realize in HTML/CSS, the wireframes and functionality will be influenced by what is feasible to build in the backend (whether from an LOE standpoint or from a performance point of view). The waterfall method doesn't allow for the full richness of this interaction to help arrive at the "optimal" way to solve a user story from all points of view.

However, if we are considering features where we want more lead time than a month, then it may not be possible to get all the way to a finished feature in one sprint. Instead, it may be enough to get to a consistent prototype, where there are designs, wireframes, and mostly-working code that can be shown at the review. All of the creative output may not be integrated yet, but it should be close enough to know that it can be gotten to a consistent state.

This is where the next sprint comes into play: the finishing sprint, where the mockups are brought to production by the same team. Naturally, they will take product owner feedback from the review into consideration during the finishing sprint.

In the simplest case, let's say we have two scrum teams. We can stagger their sprints such that when one team is in the prototyping sprint, the other is in the finishing sprint; this way we're still able to release new functionality to production after every sprint while still enabling cross-functional development of larger features.

However, we can actually take things a step further: if, during pre-planning, we can roughly separate the stories into "small" (can be taken from start to finish in one sprint) and "large" stories, then we can actually mix things out in interesting ways, like:

Sprint 1Sprint 2Sprint 3Sprint 4
Team 1SFSFSFSF
Team 2LPLFLPLF
Team 3SFLPLFFP
Team 4SF/LPSF/LFSF/LPSF/LF

Here:

  • SF : finishing sprint for small user stories
  • LP : prototyping sprint for large user stories
  • LF : finishing sprint for large user stories

So here we have Team 1 kept full with small user stories every sprint. Teams 2 and 3 are kept full with large user stories, but staggered (note how Team 3 starts with a small finishing sprint so they have something to do during Sprint 1!). Then Team 4 operates under a model where some of their user stories are small, and some are large.

I think the only operational trickiness here, from a software development standpoint, is that any "LP" work needs to happen in a branch and not the main development trunk, because it will not be production-ready by the end of the sprint. When the product owners finally sign off on an LP prototype as being ready (it's always possible that the product owners will not like--or will require significant enough changes to--a user story solution, thus requiring a follow-on LP sprint), then the first task of the LF sprint would be to port the branch back into the trunk and continue on.

Scrum thoughts: scrums-of-scrums and daily scrums

After planning, we dive right in to having daily scrums. We've gotten these to be pretty efficient (today we had a 10-person scrum finish in around 8 minutes). One key thing is starting on time--we charge people $1 if they are late to the scrum, and no one (not even the scrum master) is exempt. When we get enough saved up, we make a donation to charity (there was a thought that this should go to buy donuts for the team, but that felt a little like rewarding ourselves for being late). Our scrums are mainly a forum for people to schedule ad-hoc meetings with the people they are blocked on ("right after scrum in my office" being the most common meeting that gets scheduled). But running individual scrums is pretty well-documented and understood in the literature, I think.

As I mentioned in my post on sprint planning, we track individual burndowns on a daily basis -- how many hours does each person have left against each user story. At our scrum-of-scrums, which happens twice a week, the user story statuses for each team are put together to get an overall sprint status for the product. If you'll recall, we kept track of the global priorities of the user stories in our pre-planning session, so we can put this together in global priority order.

Then based on the time remaining in the sprint, we can again reassess confidence levels for user stories:

  • high confidence (green) : requires less than 50% of each person's remaining time
  • medium confidence (yellow) : requires less than 80% of each person's remaining time
  • low confidence (red) : requires more than 80% of someone's remaining time (possibly even getting into the "punt" range -- someone doesn't have enough time to finish their part this sprint, because they are overbooked)

The scrum-of-scrums is then a rebalancing effort. If one team falls behind, then you start to see a "striping" effect, where some of their user stories start falling in confidence, even though the surrounding user stories from the other teams stay the same. If you actually color these reports, it becomes pretty visually obvious. The rebalancing is all about trying to swap resources around such that the following principle holds:

No user story should have a lower confidence level than a user story with lower priority.

Ways that we rebalance include swapping tasks from one team to another (this is easier when the teams are vertical striped across architectural levels, as its likely that another team will still be able to do the task in question; however, a similar effect can sometimes be achieved by moving functionality from one architectural level to another (e.g. computing something in the middleware vs. the database)), or by rescoping user stories to make them easier.

Unfortunately, the way we are running sprints now ties the teams down a bit much to always make this flexibility possible. For example, a user story might say "put a Flash widget on the page that does X", and if we only have one Flash guy, we're pretty much stuck. If instead the user story said something more like: "we want a user to be able to see or do A,B,C on the page", then we might have some alternatives if the Flash guy gets overbooked.

Thursday, October 11, 2007
Scrum thoughts: sprint planning

If you'll recall from my earlier post about pre-planning, we enter into our sprint planning meetings with a stack of user stories written on large index cards.

The first thing we ask everyone to compute is the number of hours they have available for the sprint, starting with number of working days, subtracting out holidays/vacation, and then using a general availability of hours per day of productivity. We've tended to use 6 hours per day per developer, although not everyone uses that rate, particularly tech leads and team members doing double-duty as scrum masters. For these special cases we ask each member to take a guess at the number of "burnable" hours per day they will have available. Each person writes the total number of hours down on a piece of paper in front of them.

We distribute a bunch of post-it note pads and pens around to the entire team, who sit around a large conference table. We have our product owner take each user story in turn and elaborate on it. The team then poses questions to refine the requirements, and brainstorms a plan of attack. Then the fun part starts.

People start signing up for work. We'll identify all the tasks, and as we go, people will write themselves tickets on a post-it. The tickets contain a task description, a name (who has signed up for it), and an estimate in hours. When we're done, we collect up all the post-its and keep them with the user story index card. Then we move onto the next user story.

This makes for a pretty big flurry of activity -- everyone is participating, writing tickets, brainstorming, load-balancing tasks. It is anything but boring.

Each person is then responsible for keeping track of their committed hours (I just keep a running tally, subtracting each ticket's hours off my initial availability total). We then use this to assign confidence levels to each user story. If I am within the first 50% of my total available time, I'll mark my tickets with an H (for high confidence). When I'm in the 50-80% range, I mark them with M (medium confidence), and tickets written against the last 20% of my availability are marked L for low confidence.

The overall confidence for a user story is the lowest confidence of any of the constituent tickets. So just one person working on a story with a M ticket will make the whole story medium confidence, even if everyone else has H tickets against that story. The thought here is that you need all the tickets to actually complete the user story. This works out great for communicating back to the product team (and senior management), as it neatly captures the "cone of uncertainty" around the stuff that's furthest in the future. If all goes exactly according to plan, you get everything, but if something takes slightly longer, and a low priority user story gets bumped off, people might be disappointed, but no one is surprised.

Generally, this sprint planning process is one of the things I think we have nailed. There are a number of good features about it:

  • It's fun! We used to sit around and have someone recording the tickets in a spreadsheet on a laptop while everyone else watched, and man was this a low-energy, spirit-sapping exercise. It's much better to get everyone involved, and people get to write the ticket description exactly how they need it worded.
  • It's pretty accurate. We used to not assign tasks to specific people, but rather just generate all the tasks and manage them as a big to-do list where people would just pick off the next task they could do. The problem was that we would argue about the estimates, failing to take into account differing skill levels of different team members. Now, the person doing the work owns the estimate.
  • It's pretty fast. Because a lot of the discussion and ticket writing happens in parallel, you can chew through user stories pretty fast.

The main downside to this approach is that the poor scrum master has to take all the index cards and post-its and enter them into our ticketing system (we use Trac). Usually the scrum master can get away with entering all the tickets into a spreadsheet, and then we have some scripts that import them into Trac. Ideally, I think it would be fun to just use the index cards and post-its and keep a team wall going, but we're pretty cramped for space, and wall space is in pretty short supply.

Wednesday, October 10, 2007
Scrum thoughts: cross-functional teams

For a little while we experimented with truly cross-functional teams, where we had copywriters, graphic designers, UX architects, frontend developers, backend developers, and QA folks all on the same team. I thought this was great, and our planning meeting was very interactive, as everyone had things to work on for new features. There was constant collaboration throughout the sprint: design/frontend, frontend/backend, product owner/QA/UX, etc.

As a developer, this was great. We had instant access to team members from the other disciplines, able to brainstorm about how a feature should work and getting questions answered quickly. There was a very real team vibe, very exciting. A lot of the UX/algorithm worked was never documented more formally than scratched-out notes on a whiteboard (yes, I think this was awesome, because no one had to spend time creating and updating intermediate artifacts like wireframes, and no one had to spend time waiting for those artifacts -- ideas were worked out together and then rendered directly into code). The six weeks that we operated like this were really fun!

Now, we did run into some problems managing dependencies between team members sometimes--e.g. a frontend developer would end up waiting for a design to be finalized and then only have a day at the end of the sprint to get it coded up. I suspect we could have ameliorated some of this by exchanging rough drafts, for example, or simply identifying the affected user story as being at-risk. We work around this in a purely development environment by stubbing out functionality to let other people keep working, and I suspect there are similar things that can be done with the other creative disciplines like design and UX.

Unfortunately, someone (or multiple someones) came to the conclusion that it simply wasn't realistic to have the team really be cross-functional. We've now retreated to a more waterfall method where we try to get design and UX out ahead of the sprints. This makes for really boring planning meetings and daily scrums, because those folks largely just say "I'm working on the stuff for the next sprint," and I have no idea what that stuff is. We also end up having to do design and UX work again anyway, because while it's really helpful to have the designs and wireframes as a starting point, they never exactly match what we can build in a sprint, and usually require some amount of clarification/adjustment anyway.

There's a claim that design and UX work takes a long time to get just right, and so it must be done ahead of time if the full feature is to be completed in one sprint. I'm not sure I totally buy this, though, as I could really say the same thing about writing code, which is itself a creative endeavor. We figure out what's possible in the time allotted, and that's what we do. If we're not satisfied with how it looks after one sprint, then we plan to alter/improve it in the next one.

Now possibly, there is some pressure around this because we've been actually releasing every sprint to production. I wonder if having a longer release cycle spanning multiple sprints would help give folks the courage to be able to "try the possible" for a sprint, where we might spend two sprints making new features and then a third sprint to prepare it for production and get it "just right".

If anyone out there has had successful experiences with multi-disciplinary teams, please leave a comment and let us know how it works for you.

Tuesday, October 9, 2007
Scrum thoughts: Pre-planning

I think the way I'll go about my scrum discussion is to go through the order of battle for one of our sprints, at least from my point of view as a software engineer/tech lead.

We usually kick off a sprint with a pre-planning session that happens before the formal Sprint planning session. In this session, we walk through a list of asks from our product team (who come prepared with a big whopping list of them off the product backlog), put LOE (level of effort) estimates on them, and then help distribute them across the multiple scrum teams we have dedicated to the product.

We've been capturing the features on index cards in what we call "user stories" for convenience, even though they are not written in the usual "As a user, I want X so that I can do Y" format. I'll continue to call them user stories here, since that's what we call them, but you should mentally substitute "feature name" here instead.

Now, we are still essentially working in a waterfall methodology, and just running scrum within the development portion (I really dislike this, and think it's inefficient, by the way), so a lot of the feature requests are "implement page X to spec", where we get an IA wireframe and some designs handed down as the definition of the feature.

So now we have some senior engineers representing all the development teams provide a high-level estimate. We use story-point estimation for this, and play "Planning Poker" using estimates of 0, 1/2, 1, 2, 3, 5, 8, or 13 (so we go for an order of magnitude). We sometimes get into the weeds here but are getting better at quickly arriving at a common estimate. I'd say most of the engineers that participate here are roughly equally productive, and we have a rough rule of thumb that says one story point is about two developer days for us. YMMV.

So we write the story point (SP) estimates on the user story index cards, and then the product folks prioritize them. We actually stick the index cards up on the wall and then the product team rearranges them in priority order while the engineers tag them to indicate which team would likely tackle each one (according to which subsystems those teams have expertise in).

Now, given our past SP velocities, we can guess where the "fold" is likely to be -- how many of the features are we likely to actually be able to get done. We also, thanks to the team tagging, can juggle some of the tasks around to balance out the workload for the teams (especially for tasks where multiple teams could take them on). The product team may also juggle some of the lower priority items around to move things back and forth across the fold (there's nothing like saying "You probably won't get this feature this month" to see how important a feature really is!).

When we're done, we have a global priority on the user stories, and know which user stories we're going to present to each team for planning on the next day, and take down the index cards so each team can have their stack to plan with.

Analysis

Pros.

  1. Story point estimation with historical story point velocity measurement is surprisingly accurate. When we do the actual down-and-dirty sprint planning, we end up pretty close to the same set of tasks.
  2. Putting the user stories on index cards and taping them to the wall lets multiple product folks work on the prioritization in parallel, while the engineering folks can work on the team-tagging in parallel. It's also much easier to reprioritize on the wall than it is in a spreadsheet!

Cons.

  1. This is time consuming as heck. We usally spend 4-5 hours doing this for a one month sprint with about 10-12 total development resources. It is emotionally (from arguing over SP estimates) and mentally (from the length) draining.
  2. Due to the nature of our user stories, we have to actually look at wireframes in minute detail to grok the nature and complexity of a task to put an SP estimate on it. This usually means this has to be gone over twice -- once in the pre-planning meeting, and then once again in the actual sprint planning meeting. This is a direct result of having fully-spec'ed wireframes come down from on high. For example, it would actually be quicker to estimate a story like "As an editor, I would like to have a page where I can drive the content" versus one which is "As a product owner, I would like you to implement the vision of an editorial page as conceived by our design and IA teams". Especially if the design and IA teams have decided to put some complicated (to implement) features in there.

Scrum thoughts: intro

Sorry for the pause in posting--I have been a member of our support scrum team at work for the past six weeks or so, and the ensuing insanity in my work day left me too tired to post anything here. I think what I will do is pick up with a review of some of the scrum practices we're using, what works, and what doesn't, probably moving through some of the same sequences of areas as the somewhat infamous (at least around here) "Swedish Scrum" article, Scrum and XP From the Trenches. Hope you'll enjoy the discussion.