VictorSzalvay's blog

Story Point Estimates - Under-Estimating Large Items

Submitted by VictorSzalvay on February 25, 2009 - 10:00am.

At Danube, we've long espoused the value of using relative, story point estimates over estimates based on strict chronology. We've written papers on why macro metrics are better than granular task based estimates due to the inherent uncertainty latent at the task level. And we eat our own dog food; the ScrumWorks team uses relative estimation units (labeled "headaches", for fun) in estimating stories/backlog items.

Recently though, a new team member (we'll call "Ed") was baffled by the team's estimation scale. Ed had trouble acclimatizing to our estimation scale, and at a recent retrospective he pointed out some major problems with the way our team seemed to be estimating backlog items.

Famous Last Words

Submitted by VictorSzalvay on January 11, 2008 - 4:01pm.

One of the most common problems I observe in Agile teams is their inability (or perhaps unwillingness) to "swarm" on difficult problems to ensure an adequate solution. When I use the term “swarm,” I’m referring to multiple people working jointly to solve a single problem. Too often teams suffer from fuzzy logic, thinking, "Let's divide our resources to conquer the stories in this sprint more efficiently."

Fooled by Randomness

Submitted by VictorSzalvay on September 10, 2007 - 4:30pm.

Is software development a science or engineering discipline in which we can strive for perfection? Are perfectly executed software plans possible in today's market?

Feedback Driven Release Planning

Submitted by VictorSzalvay on April 18, 2007 - 10:20am.

It's been a while since my last article and that's because I've been busy as the Product Owner for Danube's ScrumWorks Pro product. That means I've learned a lot and I'd like to share one of the biggest lessons I've learned about the importance of feedback in release planning.

Hierarchial Requirements and Scrum

Submitted by VictorSzalvay on December 8, 2006 - 10:47am.

As the Product Owner of ScrumWorks, I'm often asked why ScrumWorks does not support hierarchical nesting of backlog items (i.e., user stories, PBIs, etc.). The answer is simple but highlights some profound differences in the way requirements are managed in Scrum and Agile as opposed to other methods.

Complexity Theory and Scrum

Submitted by VictorSzalvay on August 22, 2006 - 3:44am.

In this article, I try to shed light on the roots of Scrum as based in complexity science. Scrum is a framework designed to harness the benefits of "self-organizing" teams. But what does "self-organization" really mean, where did it come from, and why would it work in the software industry?

First and foremost, I'm not a complexity/chaos theory expert, but I find the subject fascinating and have done some light reading on the subject. But I'm finding that reading even pop books on complexity really help me understand the underpinnings of why Scrum seems to work so well for many organizations. As a primer, I recommend the book Surfing the Edge of Chaos which provides a business-centric overview of complexity and chaos theory, with a handful of real life business case studies.

The Mythical Part-Time ScrumMaster

Submitted by VictorSzalvay on May 22, 2006 - 3:21pm.

My colleagues and I work with a number of organizations implementing Agile and Scrum. We are starting to see patterns (and anti-patterns) emerge in the way in which many companies go about transitioning their products to Scrum. Two of these patterns are particularly disturbing: the bored, part-time ScrumMaster and permanent acceptance of the status quo. In this article I will demonstrate how these two anti-patterns weigh organizations down and ultimately lead to failure during Agile transitions. Moreover, we've consistently seen a positive correlation between successful Agile transitions and organizations that take the ScrumMaster role seriously.

Simple, But Very Hard

Submitted by VictorSzalvay on March 30, 2006 - 8:22am.

Ken Schwaber's comments in this scrumdevelopment thread are fantastic; we need to keep in mind that Scrum is a set of principles, not a call to follow a brainless list of processes.

I like something I heard Ken say during his course: Scrum is simple but very hard to do. Then he proceeded with an analogy to chess. We can all learn chess moves in a few hours, but mastery of the game takes a lot more.

So what does it take to be successful at a game like chess? I have some insight into this because much of my family plays chess, some even competitively.

Just Do It

Submitted by VictorSzalvay on February 18, 2006 - 8:13pm.

In my last post, I described how Agile methods aligns individual and organizational goals by focusing people on their responsibilities in getting product out the door. This post explores a particular role that has all but vanished in traditional phased projects: product management.

"I don't care what it takes, this needs to be done by the end of the quarter. I don't know what you expect me to do, you're the programmers!" Sound familiar?

Alignment of Individual and Organizational Goals

Submitted by VictorSzalvay on February 2, 2006 - 8:28pm.

Individuals within organizations are motivated to work toward goals that ultimately result in increased compensation, promotion, and peer recognition. Most often, however, these individual motivations are not directly aligned with the organization's broader goals. The negative consequence is that while individuals in the organization strive toward personal motivations, very few people, if any, are directly concerned with the organization's ultimate aim: delivering products and/or services to market.