ISerialized .Net, C#, Scrum and agile software development

3May/112

Checklists in software development

Posted by Pål Eie

I guess a big percent of the developers reading my blog have stopped reading already, another big percentage probably still reads, but for the sole purpose to find out what's wrong with this stupid f*** who mentions the words checklists and software development in the same sentence! http://utihagen.com/?p=116

For those how have already stopped reading, there is not much I can do, other than feel sorry for their employers who hire people who wont keep an open mind and try new techniques to make us even better developers!

In most of my professional career I have worked as a consultant, with a constant focus on hours spent vs. value added to my customers. As a rookie you are normally afraid you don't have enough work to fill the day, being a senior or an architect is the opposite, I have too many obligations, too many projects to monitor, too many customers and too little time. And how do we solve this?

I see too many who end up just being the firefighter: always short of time, always on the project where hell has broken loose, always stressed and always cranky! I got tired of being a fire fighter, got tired of being cranky when I came home to my children, got tired of saving the day!

How did I solve my problems? I started using checklists!

1May/119

Features/Epics vs. user stories in Scrum

Posted by Pål Eie

UPDATE: This post has become very popular lately, and has been referenced on several discussion forums. Please also read my follow-ups to clarify the subject even more:

  1. Follow-up 1: A testable user story
  2. Follow-up 2: Understanding features in Scrum

As Scrum has grown in popularity, the concept of user stories has made its way from theory and dust covered UML books, to developers every-day vocabulary.  In the "old days" we tended to focus on one layer at a time, instead of one user story at a time, we focused on writing large classes supposed to solve all possible scenarios for later re-use instead of simple YAGNI focused classes pin-pointing its purpose  and we focused on large-upfront design instead of gradually adapting to the maturity obtained by the customer (and developers) through the project.

We started out with allot of user-stories and even more good intentions, but ended up with phase 2 and 3 and a bunch of long forgotten concepts and diagrams. Today we are not better at planning one year ahead; we have just realized that this is almost impossible. We started focusing on business value which closely relates to user-stories. We started working with user stories weekly and we started estimating and prioritizing user stories in our Product Backlogs.