• Home
• Articles
• Newswire
• Tools
• Training
• Resource Directory

Subscribe

Recent Posts

• Writing Great User Stories
• Measuring Business Value
• Pomodoro
• ScrumWorks Pro 4 and Epics
• Scrum Comes to South America in October

Categories

• Agile 20XX
• Agile Project Management
• Scrum
• Uncategorized

Links

• Agile ALM - Agile ALM
• Agile Development
• Agile Methodology
• Agile Programming
• Free Project Management Software
• Scrum Methodology

Podcasts

Writing Great User Stories

There’s an interesting article on the Scrum Alliance about writing good user stories, requirements and use cases. According to the writer, user stories are actually narrative texts that describe an interaction of the user and the system, focusing on the value a user gains from the system. A true user story is a metaphor for the work being done. A good user story uses the “INVEST” model:
• Independent. Reduced dependencies = easier to plan.
• Negotiable. Details added via collaboration
• Valuable. Provides value to the customer.
• Estimable. Too big or too vague – not estimable.
• Small. Can be done in less than a week by the team.
• Testable. Good acceptance criteria.

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.

Measuring Business Value

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.”

ScrumWorks Pro 4 and Epics

If you work at a large organization where products are developed as constituent parts of over-arching programs, then you know how tricky it can be to track these “shared components.” Well, there’s good news: Danube just published ScrumWorks Pro 4 and its biggest new functionality addresses that very issue. More specifically, the latest release of ScrumWorks includes a feature called “epics” that allows organizations to manage the release of complex projects that include multiple components. This means that the days of brainstorming creative workarounds to achieve similar results are over. Now, users can apply “themes” (a tagging feature for quick searching and filtering) to identify all the PBIs within a given Epic. This gives developers a more intuitive approach to organizing work, while also providing Product Owners and stakeholders with a view of progress that cuts across multiple products. I think you’ll be surprised by how powerful this new feature is. You can watch a screencast here or read more about this release here.

Only You Can Prevent “Teamicide”

If the goal of implementing agile project management is to boost productivity and yield highly performing teams, then the last thing a manager or Product Owner should do in that environment is stand in the way. And yet, this article on InfoQ describes how managers—out of intimidation, confusion, or both—have a tendency to undermine their best teams. Authors Tom DeMarco and Tim Lister have dubbed this phenomenon “teamicide” and Steven Denning, who has been writing on high-performance teams for InfoQ of late, offers two common management attitudes that can kill a great team:

“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.

The Myth of Velocity?

I just ran across an article on InfoQ discussing the phenomenon of hyper-productivity—one that tends to come up a lot in relation to agile practices and Scrum, in particular. Apparently, the Scrum Development Group has seen some lively debate erupt around the topic, as trainers such as Tobias Mayer suggest that any attempts to measure hyper-productivity is “a waste of time.” Certainly, I understand his suspicions over Jeff Sutherland’s claim in a recent presentation that to be hyper-productivity is constituted by a rate of 300 percent improvement over three two-week sprints. As Mayer points out, it’s all relative. If a team accomplished nothing in a given sprint, then realizing a 300 percent improvement would be a snap. But it hardly means the team’s hyper-productive.

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.

Agile Dogma

One of the biggest criticisms against Scrum and agile evangelists is that their all-or-nothing attitude undermines the very improvements Scrum and agile promise. Of course, those of us who do practice by-the-book Scrum and agile understand why it’s so important to hold fast to those principles and processes: because they’re the key to unlocking increased productivity, accelerated cycle time, and reduced overall costs. But in his article “Agile Development: Dogma Vs. Degree,” which recently appeared in the online edition of SD Times, David Rubinstein makes an important distinction that often gets lost in the midst of so much evangelist noise. He writes:

“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.

Agile Experts on the Backlog

Based on an earlier discussion of the vitality of the product backlog (according to Dave West, the author of the original article, it’s important, really important), numerous conversations have popped up on user groups and beyond. Best of all, it seems everyone who has chimed in has a slightly different opinion. In the face of so little consensus, InfoQ decided to back up and go straight to the experts with a set of questions about the backlog. After assembling a “virtual panel” that included such agile heavyweights as Mary Poppendieck, Ron Jeffries, Jeff Patton, David West, Steve Freeman, and Jason Yip, InfoQ threw the following five questions at them:

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

Does Size Make Standups Fall Apart?

I just saw this post up at InfoQ (http://www.infoq.com/news/2009/04/large-team-standups) which discusses how well Scrum’s daily standup meeting functions when teams grow increasingly large. For the Scrum users cited in the article, there’s no mystery as to how useful they are for large teams: not very. According to them, as team size increases, these meetings drag on, fail to hold team members’ interest, and, consequently, individual reports are delivered out of sequence. Those who have tried to use Scrum-of-Scrums to address this problem have found that it doesn’t improve things much, either, explaining that the level of overhead increases exponentially with the depth of the Scrum-of-Scrums (i.e. the number of layers).

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.

Free Educational Resource for Scrum Teams

I don’t know about you, but I’m always searching for great materials—articles, books, blogs, and so on—that explain agile project management methods and techniques in a clear and concise way. I’m trying to amass an archive of materials, so that when a new member joins my team or another team at my organization decides to pursue agile methods, I can offer some literature to help them find their bearings. One place I look for these (and I highly recommend you look there, too) is Dzone (www.dzone.com), which publishes “Refcardz,” a.k.a. educational resources for developers. In the past, most of DZone’s Refcardz have been deeply technical, but its newest one focuses on the popular agile project management framework, Scrum.

Authored by Danube Certified Scrum Trainer Michael James, this new Refcard is exactly the kind of document I’d want to give to someone who had just joined a Scrum team and needs to learn the basics fast. It is very readable and doesn’t get caught up in tangential conversations that would distract or confuse a newbie. Instead, it simply defines Scrum’s most foundational, non-negotiable elements: its roles, meetings, and artifacts. Scrum is a very skeletal framework and James does an excellent job of explaining them in a linear fashion that’s easy to follow, even for the uninitiated. Elsewhere, he provides his insight on related practices and the challenges of scaling Scrum teams across very large organizations. In all, it’s a comprehensive introduction to Scrum’s fundamental tenets and a few of the most relevant topics for practitioners.

Download the pdf of Michael James’ Scrum Refcard below and use it to train new members of your Scrum team.

Scrum_Refcard.pdf

The Jolt Product Excellence Awards

For companies in the tech sector, the Jolt Product Excellence Awards are the Academy Awards of innovation and efficiency. The finalists in the thirteen categories are online now: http://www.joltawards.com/finalists.html

You’ll have to wait until the SD West conference in March to find out who takes home the trophies, but there’s one category in particular I’m invested in: Project Management. For those of you who follow the site, you know that my team uses ScrumWorks Pro and that we’ve found it just blows away all the other agile tools we’ve used. Danube’s product is a finalist in that category, along with CASE Spec, Pivotal Tracker, Rally Enterprise, and TargetProcess. May the best tool win…

Next Page »

Collabnet is a project success company specializing in the improvement of management and engineering practices for software development organizations.
Continue reading »

Agile Tools

The next generation of agile project management.
Continue reading »

Agile Training

Offering several training options on software process improvement. Our agile project management courses are designed to provide your organization with a foundation in the principles and skills necessary to benefit from Agile methods. Classes are offered both as public and private in-house sessions.
Continue reading »

Copyright © 2008 Agile Project Management  Free Project Management Tools   Project Management Classes