Information based backlog prioritizing

The general rule for prioritizing the backlog is that you do it based on business value. From the business perspective, this makes a lot of sense: you maximize the ROI by doing first the things that create the most value in the context of your product, be it monetary or non-monetary (e.g. number of visitors on the website, number of registered users etc). You define the goals during the release planning and then you make sure that you’re going in the right direction.

The second level of prioritizing happens during the sprint planning meeting. The team looks at each story and tries to see if the story is ready-ready, meaning if the Product Owner says it’s ready for the team and if the team thinks it’s ready to start. So actually the highest business value is not useful at this point anymore; instead, there’s something else.

It’s about information.

Continue reading “Information based backlog prioritizing”

Better User Stories

Some of my readers may already know that I like to challenge every practice that is accepted as norm in software development. I always ask a few questions:

  • What is the value of the norm?
  • How can we get the same value in other ways?
  • Is one of the above ways better (or at least worth mentioning)?

I’ve recently realized that one of these norms in agile software development is user stories, and I will especially discuss the way we write user stories.

Continue reading “Better User Stories”

Don’t let your methods look like this!

Don't Let Your method look like me!

I drew this picture with Corey Haines at the Krakow April 2011 Code Retreat. I started with the overall silhouette of the method, and Corey added the eye and the comment. In the end, I think we got an excellent motivational poster. So, developers, don’t let your methods look like this!

The right bottom corner is about another thing you should remember: at least know the name of your pair before starting to program. It’s funny how many times I’ve seen developers jumping right into the problem and forget this simple thing.

In the end, many thanks to the people who made the Code Retreat Krakow such an amazing experience. Pair facilitating with Corey is always an awesome experience, and I’d love to do it more often. I loved the energy of the participants and I’m really proud of the T-Shirt. Corey, Krakow, see you again soon!

Yes, you can deploy every two days

Maria and I spoke at the Agile CE conference about a method of work that we use to help teams deploy every 2-3 days. Here are the slides.

Some impressions immediately after the talk:

  • Corey Haines told me that he uses almost the same method, only in a team of 2
  • “Bucket planning” seemed to catch the attention of a few participants. Basically, the idea is that the capacity is fixed and you should only decide what can fit in the capacity

Continue reading “Yes, you can deploy every two days”