mikkeman.nl

Being a Product Owner (PO) is not the most easy role on a (Scrum) project. In fact, it might be the hardest role. POs are easily faced with months and months of requirements in the backlog. They are supposed to prioritize this huge list (“is requirement XYZ more or less important than requirement ABC?”), making sure that the needs of stakeholders are met.

And please make sure there is enough ROI, dear Product Owner!

And attend the daily scrum to clarify any issues the development team has within the current iteration!

And prepare the next set of requirements for planning.

And… And… And so on.

Jeff Patton wrote an excellent article about the assumption that the Product Owner must possess super powers: The product owner and the product-shaped hole. Unfortunately, most Product Owners do not possess super powers. I might even say that not a single PO has them (since they are still exclusively used in comics and the like).

This post deals with one of the challenges a PO has: how to prioritize my backlog?

When asked to prioritize every requirement on a scale of 1 to 3, the following usually happens:

• 80% will end up as priority 1
• 10-15% as a priority 2
• the rest (if any) is priority 3.

That is not very helpful to determine what requirement(s) to work on next.

A useful approach in this situation is to limit the number of requirements that are allowed in priority 1 and 2. For example:

• 10 requirements are allowed priority 1
• 20 requirements are allowed priority 2
• the rest is priority 3

All priority 1 requirements must be ready for immediate scheduling in the next planning meeting. Suppose that 8 requirements fit for the next iteration, then all you have to do is:

• promote 8 requirements from priority 2 to 1 and;
• promote another 8 requirements from priority 3 to 2.

That is just a minor task compared to the task “rank every requirement against all others”. When you put the priority 1/2/3 boards on the wall with brown paper and postits, it provides visual focus as to what to work on next as well as a transparent overview of “what’s next” and “what’s almost next”.

Try it, you might like it!

My usual day doesn’t involve a lot of technical stuff, but once in a while I happen to enjoy an evening with editors and revision control systems. Once in a while is not often enough to memorize all tips and tricks about branching, tagging, merging and working copies.

I used to use the TortoiseSVN -> Merge dialog for merging changes from trunk to a branch. I find this dialog quite… confusing. What source? What revisions? Yesterday evening I found an easier solution for this. I decided to put it up here, I’m sure I’ll need it again someday. And perhaps there are some people out there that might find this helpful as well.

I assume an up-to-date working copy, all changes committed, no conflicts with the repository.

Right click trunk, pick TortoiseSVN -> Show log. Select the revision(s) you want to merge, right click and choose Merge. Pick a folder in your working copy to merge to, click OK, and presto, done.

Piece of cake. Do Not Forget This Anymore.

photo credit: criggle1

…but some people tend to treat them that way.

Lately, a lot of agilists are discussing differences, similarities and (in)compatibilities between Kanban, Lean and Scrum. Google is your friend here, search for “scrum vs kanban“, “scrum vs lean” and “lean vs kanban” to get you started. In this post I’ll add my opinion to the discussion.

Scrum is a very popular framework for managing the software development process. It has a small number of roles, artifacts and meetings, which makes it easy to grasp. Scrum gives you some guidance when starting out with an agile development process. It is based on multidisciplinary teams that are authorized to do whatever is necessary to deliver working software to their customer, working in short iterations to enable fast feedback and delivery, regularly inspecting and adapting their process for improvements.

More about Scrum can be read here, here and here.

Lean is a mindset. It is used for production environments (e.g. the Toyota Production System) as well as product development environments. Depending on who you ask or what you read, there are several principles you should adhere to. To quote Womack and Jones, these principles are:

• Identify value
• Map the value stream
• Create flow
• Establish pull
• Strive for perfection

The Poppendiecks have translated these principles to software development in their book “Lean Software Development” and added twenty-something tools you can use to create and support a lean software development process. Their book is recommended reading (if you haven’t already).

More on lean can be read here, here and here.

Kanban is very closely related to Lean. When people use the term Kanban, they mostly mean “kanban system”. A kanban is literally a “signal” that can be used to trigger activities in your value chain. In fact, a kanban is a tool to implement lean principles like flow and pull. Every piece of work needs to flow through all activities to create value for the customer. Kanbans are used to make sure that there is not too much work-in-progress and everybody in the value chain focuses on the work at hand. A kanban also points out bottlenecks in your value chain if a certain activity takes unusually long and redirects all efforts in the value chain to elevate the bottleneck.

More on Kanban can be read here and here.

To me, Lean and Kanban are synonymous with respect to software development. The Kanban movement promotes a lean process to deliver software. It lets you think about your value stream, gives you tools to make work flow and lets the customer pull that work. Combined with a regular reflection on process improvement, Kanban equals Lean.

Scrum and Lean are not synonymous. However, they do share common ground in their principles. Scrum has a strong focus on value creation (just as Lean), limits work-in-progress to a “sensible” amount each iteration, puts the customer in control (pull, which is controlled by Sprint Planning) and has regular process improvement meetings (Sprint Retrospective). They mostly differ in how they apply practices and tools to the situation at hand.

Scrum and Kanban are also not synonymous (which follows logically from the previous two paragraphs ). To me, the biggest difference is whether to use iterations or not. The Kanban movement eliminates the need for iterations, while Scrum makes extensive use of iterations.

The real question is of course not what differences, similarities and compatibilities exist, but what method/framework/mindset to use? The consultant answer here is, “it depends”. Every project, team or organisation has its own context where one or the other may be a better fit. There is no “single best answer”. Generally, I would advise Kanban in a context where priorities tend to change much quicker than the length of an iteration, while Scrum is a better fit if priorities are usually stable throughout the length of an iteration. And I would advise everybody to use lean principles in every problem at hand, no matter what tool you will use to solve it .