The writer draws interesting comparisons between “traditional requirements”, “use cases” and “user stories” – and the benefits and pitfalls of each. Are user stories better than other types of requirements specifications? Well it depends. It’s essentially the team that determines whether a particular technique will work or fail. For most scrum teams, the intent of good user stories, however, is to help foster collaboration. If you already have a collaborative team environment and/or are looking to enhance it – read this article for learning more about techniques for writing good user stories.

For stakeholders and managers, the single most appealing aspect about project management with Scrum is almost always the fact that all development efforts are driven by Business Value. That means that work is prioritized based on the amount of value it will generate for the organization. In an article called “Estimating Business Value,” InfoQ’s Chris Sims considers how teams can determine which user stories represent the highest Business Value. What ensues is a comprehensive discussion of how organizations do just that. Perhaps most interesting is Pascal Van Cauwenberghe’s assertion that Product Owners should not select user stories they believe to contain the most business value, but should first consider what generates business value and then work backwards to write the user story accordingly. He offers a step-by-step process to guide Product Owners through that process for the first time:

• “We first decide what values (or benefits) we want to achieve before launching a project or product
• “Then we find and improve the business processes that deliver that value
• “Then we find and improve the supporting business processes that make the value-delivering processes possible
• “When the team needs user stories, we take the highest value processes and break them down into user stories at the right level of granularity for the team’s needs. The team pulls the stories, so we only generate a minimal set of user stories.”

The article continues with additional approaches for teams to weigh, including suggestions from Brandon Carlson, Mike Cohn, James Shore, and Kelly Waters. It’s a valuable post for providing so many perspectives to this one problem. To their advice, I’d also recommend consulting Michael James’ whitepaper “An Agile Approach to ‘Metrics’: Applied Macromeasurements to Ensure On-time Delivery” and Dr. Dan Rawsthorne’s whitepaper “Monitoring Scrum Projects with AgileEVM and Earned Business Value (EBV) Metrics.”

It seems that excitement over agile processes and engineering techniques has finally migrated southward. Well, not “finally.” Last fall, Buenos Aires played host to Ágiles 2008, the inaugural South American conference on all things agile. But last month, the official website for Ágiles 2009 went live. This year, the conference moves to Florianopolis, Brazil for four days of “agilidad” in October.

With retrospectives guru Diana Larsen and Agile Manifesto signatory Brian Marick slated to deliver the keynote presentations, it looks like a great program, whether for South American software developers or North American coders looking for an excuse to mix business with pleasure.

Check out the full program here.

“Sometimes it’s murder—death by intent to kill: high-performance teams often achieve what they achieve by breaking the rules of the prevailing corporate culture. Managers can feel threatened and so they disband them, in order to preserve the status quo.”

“Sometimes it’s manslaughter—death by negligence: the management doesn’t understand the high-performance team or its mode of operation and so it does things that unintentionally eliminate high-performance, e.g. moving members of a high-performance team to other teams, ostensibly with the goal of creating more high performance teams but typically with the result of eliminating any high performance.”

Have any of you experienced the scenarios described above? I’d be curious to hear if many of you readers have experienced “teamicide” at your organization. And, lest we end on such a negative note, be sure to check out the end of the InfoQ article, which concludes with some great tips from Ominlab Media’s Stefan Gillard for finding individuals who will likely contribute to a high-performance team.

I suppose my take is that yes, the notion of “hyper-productivity” is somewhat beside the point, but measuring rates of improvement over time is absolutely essential to push a team to grow and increase its capacity. However, it’s essential for the team, not to be compared to some gold standard of hyper-productivity.

One reason cited for the relative uselessness of such a metric is that, in Scrum and other agile environments, work is estimated in terms of story points—an abstracted unit of difficulty that is agreed upon by the team. Because these units possess no direct correspondence to the amount of time required to complete work, they remain, at best, estimations. However, team members who work together over time typically develop a common of understanding of their estimating system and do, in fact, begin to assess work in a consistent manner. Thus a team’s rate of improvement is reliably measurable—just not in the sense that Sutherland suggests. While identifying an absolute measure of hyper-productivity misses the point, having a trend line to refer to as an indication of improvement over time is still valuable for teams.

“On one side of the argument are those who believe that adopting any of the steps is a move toward agility; that the important thing is not adherence to the steps but instead an improvement in the organization’s software development.”

What I think is important in this quote is Rubinstein’s articulation that the end goal of adopting agile or Scrum is measurable improvement within the organization, not perfectly complying with every aspect of the methodology’s processes. Again, the “rules” of Scrum and agile are there for a reason: They give teams guiderails to lean on during the difficult process of wide-spread organizational change. But an organization does not win if it adopts every aspect of an agile method. They win when they realize change within the organization and begin to work in ways that lets them do things they never could before.

One note: I found it interesting that Rubinstein decided to interview a representative from every major agile tool vendor except the one that we use! In case you’ve missed it in previous posts, we use Danube’s ScrumWorks Pro to manage our projects and it’s really great—mostly for being so easy to use and aligned with the Scrum framework. If you’re using Scrum and find yourself in the market for a tool, you should definitely look into this one.

1. What is the purpose of a backlog in your opinion?
2. How would you define a backlog?
3. When/where should a backlog be considered waste?
4. When/where should a backlog be considered essential?
5. Is there a question or questions that I should have asked and I haven’t? If so, please ask and answer.

There’s a still a healthy amount of differing ideas even among this group, but some commonalities do emerge. You can take a look at all the responses here: http://www.infoq.com/articles/backlog-panel

As I read through all of this, I couldn’t help but think, “Well, of course, standups break down when you try to use them with really big teams!” Scrum is designed to succeed under the recommended conditions. That is, all Scrum literature advises that teams should be cross-functional and composed of seven team members, plus or minus two. That’s a range of five to nine—pretty small, really. So it’s a no-brainer that these teams aren’t getting the advertised results. Would you stuff 30 people into a five-passenger sedan and expect a comfortable ride? Of course not! The same principles apply here.

One valuable point of inquiry in the article was the problem of scaling. I work for a small company that has never had to implement a Scrum-of-Scrums hierarchy, so I’m hardly an authority on the subject. But if you are, I’d be curious to hear some of your strategies for making that configuration work.