Heather McLean

A while back, Mike Cohn posted a concise explanation of how story points relate to hours. It’s a common phenomenon; folks who are used to traditional project management really want those points to equate directly into, “how long will this take?” The important thing to remember is that story points are a measure of capacity and effort, not time. The next thing to remember, and this really messes with teams new to agile methodologies, is that story points are mostly meaningless until you have accumulated historical data. Without some data on trends, a story point really is a guess; what does 1 point mean versus 8 points when this is your very first iteration? You have to go on gut feelings, and there will be resistance to that kind of “guesstimation”—which is pretty sad when you realize that guessing hours is not much better than guessing points.

At least with the points, you’re admitting that it’s an estimate. Hours tend to lull people into a false sense of security, assuring them that this is the timetable, and if you deviate from the established time line, then it’s the implementers’ faults, not the estimators’. Which brings me to another important part: story points are estimated by the team, not by a single project manager dictating from on high. This puts the onus on the team to estimate better with each sprint (which they will, given the freedom to do so), instead of being forced into a death march to meet arbitrary time limits.

Estimating story points is an ongoing learning experience. You start with none and build from there; once you’ve had three or four iterations under your belt, you’ll notice the team getting more accurate. All one point stories will start to look similar and take similar amounts of time, and once you have that in your arsenal, estimating with the story points both generates a realistic timeline and gives your team some breathing room.

So I’ve gotten really used to the idea of thinking in terms of individual stories/tasks when I work, and I like the visual cue of a task board. I haven’t been able to convince everyone that this is the best idea yet, so I’m leading by example. Here’s a shot of my “personal task board” that I have in my workspace.

Personal Taskboard

You can see several columns from right to left: NR (not ready/undefined), Rdy (ready to implement), WiP (work currently in progress), and Done. The tasks are written on individual sticky notes with a description, the ID number from our defect tracking system (if any), and the product release it is assigned to (if any). They’re assorted roughly in priority order with higher priority items towards the top of the board.

I wanted to take a minute to pass on a very insightful article by Tobias Mayer:

Oppression, Revolution and the Future of Scrum

I won’t add any commentary this time, just go read it for yourself.

As an aside, I realize that this is a pretty weak post in light of my long stretches of silence. My current project has me pretty busy, but hopefully I will have some more discussions on agile and whatnot in the near future.

Well, I think I had a big win today with the director for my current project. He agreed that the waterfall way of doing things is not working well for us, so we spent an hour-and-a-half discussing project methodologies as a team. By the end of it, I think we had him sold on iterative development (we’ll work on other aspects of Agile later, of course).

Afterward he sent an email out with the things we had agreed upon, and at the top was a direct quote from me:

Deliver faster, deliver more often.

I’m not ashamed to admit that a recent post from Dave Nicolette reminded me of myself. After spending most of the past year being indoctrinated with Scrum, it is very, very tempting to start trying to apply iterative development to everything. I mean, why not? Iterative development is superior, right?

As with all things, the answer is “not always.” With my current project, the temptation is high. The organization and the project already exhibit several agile/XP qualities:

• Continuous integration.
• 30-day release cycles.
• The project has already been broken down into smaller chunks of deliverable features.
• We do daily status meetings. (Although they are an hour long and much less focused than a daily stand-up.)

As you can see, it has the potential… on “the cusp of greatness,” you might say. It would be tempting to think that we could just overlay Scrum or some other form of iterative development and succeed, and trust me, it is very difficult to resist that urge to evangelize Scrum. However, there are several factors that mean I must take a healthy dose of reality first:

• The organization has no agile history, and I would bet that 99.9% of the managers and developers have never heard of agile development, let alone practiced it.
• The “product owner” currently lacks the discipline/desire to commit to a set of requirements for any length of time. (We would be aborting sprints right and left.)
• Policy prevents us from actually working on anything until it is completely designed and documented. (Of course, the policy is not always followed 100% of the time.)
• The developers are not accustomed to self-managing.

Those are just a few off the top of my head. As you can probably imagine, trying to throw Scrum into the mix here would not work out so well. On top of the above hurdles, it would be a hard sell to management, and I have a feeling any initiative would be quickly abandoned if positive results were not immediate.

Still, that doesn’t mean I’m not going to try at some point. I just have to be subtle and introduce things one step at a time rather than going whole hog from the beginning.

I haven’t posted in a little while, so I just wanted to assure everyone that I’m still alive. I had a nice week-long vacation, and now I’m working on getting up to speed on a new project and company.

In the meantime, here’s a little gem from Dave Nicolette that I found amusing and sadly true:

Why is agile software development like teenage sex?

It’s on everyone’s mind all the time.
Everyone is talking about it all the time.
Everyone thinks everyone else is doing it.
Almost no one is really doing it.
The few who are doing it are:

• doing it poorly,
• hopeful it will be better next time,
• not practicing it safely.

The Discipline of Agile (followed from a post on Mr. Appelo’s blog) made me pause and think. Mr. Ambler’s article does an excellent job of breaking down agile into some key disciplines:

1. Regular Delivery
2. Quality
3. Active Stakeholder Involvement
4. Scale
5. Teamwork

I was thinking, though, that the list was far too specific. Some of these things are results of similar disciplines—for instance, Active Stakeholder Involvement and Teamwork are both principles of good communication. Others are esoteric, such as Scale.

I decided to reorganize these disciplines a bit and change them around, hopefully making them more broadly applicable to agile processes. Below are what I believe to be the disciplines of an effective agile/lean project.¹ Read the rest of this entry »

One of my teammates shared this little story with us last night, so I thought it would be worth it to pass it on.

Ready, Fire, Aim is a play on Ready, Aim, Fire, a phrase commonly used in conjunction with firearms. Since firearms are used extensively by the military, the first counter story I want to share comes from the US military.

General Norman Schwarzkopf commanded US forces in the Persian Gulf during Operation Desert Shield and Operation Desert Storm. He is credited with taking advantage of technology advancements in weaponry to aide his success during the Gulf War. One such advancement involved putting soldiers on top of buildings in Iraq. These soldiers would remain hidden during daylight hours. At night missiles would be fired from several miles away. After the missiles had been fired, the soldiers on the rooftops would use lasers to guide (aim) them to their targets—truly a Ready, Fire, Aim operation.

A Scrum team is similar to the soldiers on the buildings, constantly guiding their projects to the desired targets.

I just exited a productive mini-meeting about improving estimation of hours and story points for our off-shore teams. One team in particular is struggling, and we got together to brainstorm some ideas on how to help.

I came up with a couple of suggestions that we’re going to try:

• Get the team to think in relative terms. One of the problems is that when the team comes to the table to estimate stories, they start pointing things randomly and in isolation from one another. In other words, a 3-point story might not match a 3-point story in the previous sprint in complexity, or even with another story in the same sprint. As an exercise, when the team is estimating, we will stop and ask them, “So how does this story relate in complexity to this story over here that you gave the same number of points?” Hopefully it will get them to stop and think about it long enough to reassure us that the points are consistent.
• Get the team to sort user stories by difficulty prior to sprint planning. This will hopefully also increase teamwork. The idea here is that prior to the actual sprint planning, the team will get a list of stories that the product owner is thinking about including in the sprint. Then they can, on their own time, work out the list in order from least complex to most complex to implement. Theoretically, by the time they get to sprint planning, they should already know which stories should be estimated higher than others.

We’re not sure how exactly this will work out, but at this point we’re willing to try anything to improve the team’s ability to plan and estimate.

A coworker recently turned me on to the Google Tech Talks Channel on YouTube. There is a wealth of good information on many different topics. In particular, I found this presentation about leadership from Mary Poppendieck especially insightful this morning: