Whatever Happened to Risk when We Went Agile?

There seems to be some sort of rallying cry that Story Points and, in general, estimates, should be gotten rid of entirely from any sort of software development process.  I think this is, generally, a very strong kneejerk reaction to some pains through the development and release process in terms of managing expectations.

Usually said pains come from someone managing expectations in the following manner:

• A Release is planned with a set number of User Stories define
• Said user stories are pokered 
• Project Manager compares the sum of the user stories against the team's velocity and converts that into sprints - let's say they determined that it sums up to about 4 sprints.
• Project Manager sets a release date approximately 4 sprints from now.
• Project Manager attempts to hold team accountable to the Release Date.  The word "commitment" seems be the word of choice, lately.

The most glaring issue with this situation is something that doesn't get mentioned a lot in the agile process: accounting for risks when managing expectations.

We've all probably seen various different risk charts that show likelihood vs. impact with mitigation plans associated with each.  These have all but disappeared.  Granted, I'm not saying that a team should get back to long drawn out risk powerpoints, but it's the team's responsibility to bring up these risks.  It's usually the project manager's responsibility to communicate these risks out.

I get the impression that a lot of agile teams have lost sight of actively tracking risk and reflecting it back to project stakeholders.  It's not like they've gone away because you're doing Scrum.  

Here's my unscientifically backed opinion on medium to long term estimates: shoot from the hip estimates in terms of resources and man-hours from an experienced manager, in conjunction with a development leader or two, is just as good as a thoroughly pokered out backlog.  You take a look at it from a high level, identify some risks, and based on what you know from the team, manage the expectations of the stakeholders.  

Some may argue that more vague stories with point values far exceeding your sprint threshold are just as good.  I actually don't have much direct experience in trying that, but it would also be something to think about.  When you get story points that are as high 100 points, to me that's pretty much the same as a shot from the hip.

The last thing you want, however, is to attempt to define all the lower level user stories at the beginning.  You will find yourself spending an arduous amount of time at once to try to estimate something months in advance and opening yourself to the challenges that impact Waterfall.

In the end, it all boils down to plain ole communication, including the appropriate people in the decision making process, and getting buy-in for the final decision.  At the very least, you didn't spend an ungodly amount of time holed up in a room trying to think of every single thing for the next couple of months.

So why poker at all? Well, there are a boat ton of uses where pokering, with Story Points in particular, is very useful.  This post is getting long so I'll talk about how they help smooth out the process from sprint to sprint in the next post.