Category: Agile

The size and shape of an ideal Product Backlog

How long should a Product Backlog be? How should it be organized? Is there a universal rule of thumb or is it product-specific?

Continue reading “The size and shape of an ideal Product Backlog”


Does it make sense to develop an MVP iteratively?

Are the concepts of the MVP (Minimal Viable Product) and iterative development related? Do they try to solve the same problem in a different way or are they complementary and can be used together?

Continue reading “Does it make sense to develop an MVP iteratively?”

Passion vs engagement – how to attract and keep the top talent

Several weeks ago, I’ve read a Henrik Berglund’s post on the blog that really struck a chord with me. In a nutshell, its message is that to stay competitive on the current market, the passive expertise of your employees is not enough, they must also be deeply engaged or even truly passionate about what they do for you.

Continue reading “Passion vs engagement – how to attract and keep the top talent”

Don’t mix roulette with poker – a recipe for better estimations

During a planning poker estimation we hide cards until everybody makes his mind and then we reveal them all at once. We do that to make the estimation more objective, unbiased.

One obvious bias that could skew our estimation is influence of more experienced, or just more vocal, team members. The pressure resulting from their self-confidence can impact our estimate, make it gravitate towards their opinion.

However, there is also another strong, but not so obvious bias: the Anchoring Effect.

Continue reading “Don’t mix roulette with poker – a recipe for better estimations”

Impeded work in kanban is a “critical error” state, not “waiting”

During a discussion about a WiP (work in progress) limit for the “development” column of our kanban board, a question appeared: what should we do if a story is blocked for some reason during development?

My answer was to mark the impeded story with some eye-catching token (e.g. big, red exclamation mark), “stop the production line” and focus on un-blocking the story as quickly as possible.

This raised a lot of doubts. Why should we stop the production line in such a case? Why can’t we simply multitask for a moment and work on another story, letting the impeded story “hang” idly on the board until it becomes un-blocked?

Continue reading “Impeded work in kanban is a “critical error” state, not “waiting””

How much time do you need to fully clean up your code?

Serious quality improvements require investments right now, while promised benefits wait somewhere far in the future.

Cleaning a messy code base will allow your team to speed up, but first, its velocity will drop, consumed by all the refactoring work needed. Implementing TDD will make adding new features a breeze, but first, time must be spent to configure necessary tools and to learn.

This makes people uneasy.

Continue reading “How much time do you need to fully clean up your code?”

What’s your company’s real culture?

A culture is trendy.

It has become fashionable to brag about a company’s culture. Companies advertise themselves as having a startup-like culture, agile culture, craftsmanship culture – or whatever culture is hot at the moment.

Such cultural claims are shown off in job ads, conference talks and mission statements. They are sometimes even codified in procedures.

Fine and dandy. But does the actual, day-to-day behavior of the company’s employees affirm them?

Continue reading “What’s your company’s real culture?”

5 things you have to remember to really “inspect and adapt”

One of the fundamentals of Agile methodologies is the “inspect and adapt” approach.

What does it mean to inspect and adapt? It means that instead of planning (guessing) everything up-front waterfall style, you regularly reflect on your current situation and change your behavior accordingly.

To make such an approach work well, you must keep in mind a few rules:

Continue reading “5 things you have to remember to really “inspect and adapt””