- Developers are unhappiest when they don’t have enough to do.
- It’s possible to get a massive amount of work done when the overall experience is fun and/or rewarding.

A good point about risks. One shouldn’t just blindly put items according to the value points initially assigned by the product owner. Every item should be prioritized not just only from business value, but also according to risk, dependencies to others, and other input from developers and other stakeholders. The product owner should have the final say though.

/Joakim

I like the complexity/importance graph, that is an interesting way to look at stories. Another axis I consider is risk, what looks risky gets higher priority. This may or may not correlate to complexity, for example it could be an interface to an external system where the team has to deal with unknowns, a different company, etc. Highly risky items are by nature high priority.

We have used a similar points scheme for business value, however if the project has an expected return on investment, we’ll use points and weight that investment across the backlog. It has some very interesting effects on product owner and business customer behavior. I recommend trying it.

cheers,
Robin Dymond

But now that you mention it, I don’t know that I need that flexibility and therefore my code is perhaps more complex than it needs to. I should perhaps have waited until I needed that flexibility and then refactored the code.

The dynamic nature of Ruby may have been the way to go. I’ll play around with both approaches and see what feels most natural to me.

Thanks for the input.

Of course there are other reasons for creating factory classes, but often they are created just in order to be able to inject mocks. While this is necessary in languages like Java (at least without delving into bytecode), in Ruby its possible to use meta-programming to achieve the same effect without cluttering code with factory classes.

I actually like not having calls directly to the constructor from my production code. I like the way the class gets decoupled from an actual implementation of the interface it needs.