Thursday, April 17, 2014

Scaling Agile @Allegro by Krzysztof Dąbrowski

This talk is in Polish only.
Krzysztof was a CIO at Allegro Group while Agile (Scrum) transformation. Here's great talk on how the company evolved.

Wednesday, April 2, 2014

Estimation Scale

If you have been following me on social media you might probably know that I am not a big fan of Fibonacci series scale for user story estimation. Don’t get me wrong. There is nothing bad about it, although it’s very problematic for a team that begins their journey with estimation.

The problem with estimates

At the Planning meeting when developers try to estimate tasks length (or Story Point value) they generally encounter the situation where there is a small difference in values assigned to tasks by team members. Let’s see the real world example. We have a team of five developers and they estimate task with following values: 2, 3, 1, 2, 5.

How to pick the final value? Calculate arithmetic average, use median value, pick the biggest one (in order to have a small buffer just in case) or confront the guys that assign the lowest and greatest values? In my opinion non of this techniques is perfect. The average will fail while there will be large difference between two edge cases. Adding buffer to your tasks is bad by definition and should be avoided. The median seems to be alright although it will not take under consideration the arguments of this 5 story points guy and assign value of 2 to the task.

Why we have Fibonacci scale?

When your team do first take on estimation, it probably will fail in both providing accurate values for length and do not take the risks under consideration. Whenever you ask a developer to estimate time in hours and confront the result with the another one, there is a hight probability that you’ll end up with two completely different values.

To address that issue and to narrow down possibilities of mismatched values we have introduced the discrete series that limits the number and rise the chance to match two estimates. This is the reason behind this list of unique integers like 1, 2, 3, 5, 8, 13, 21… The main problem with this scale is that the list is too long and unnatural to us, developers.

Small, Medium, Large Scale

While you approach the problem of to long scale you might want to narrow down the list of possible assignable values to only few. That will increase the chance to match the story points values of several team members. Let’s start with Small, Medium, Large. Each task in your backlog could be assigned in just a few seconds to any of those categories.

Small, Medium and Large is so familiar to us, that even a junior developer or business oriented part of our team can take a part in technical tasks estimation. After just a minute of discussion the consensus could be made and the team will end-up with consistent and unified value for a task. How to measure the size of a task? Take the one man-day as a reference system. How big in comparison with the one man day of work this task is? Small (just a quick fix), Medium (around the half of day), or Large (bigger than half day, but do not exceed one day mark).

To big to be large

But what with the bigger tasks? Fear not. If you’ve done your job at Grooming (Refinement) you will be able to break down your tasks into a max one man-day long ones. Yeah, but we’ll end-up with a sea of small user stories that does not give us a business value… That’s the reason why we have Epic Stories. If you took a smart way of dividing your business roadmap into Epics A.K.A. features packs you might track the progress towards releasing a full featured new functionality.

There are technical stories that we might use. Indeed, although it seems to be a clear way on how to manage a large sets of stories, it scales badly in almost any tool, that supports agile software development I have encountered so far. Technical tasks has problems with being completed or transferred between two sprints (in case you haven't manage to complete the task within a single sprint). Moreover when you use a Stories you might be able to not only split your functionalities into smaller, deliverable and more predictable features, but you might also be able to execute tasks in parallel by several team members. That pushes you towards the goal!

The power of two estimation scale

I’d like to suggest using an estimation scale based on the power of 2. Why? I’ll give you a simple and quick example. What is the value of the 10th element in Fibonacci scale? You have to hold on for a minute and calculate. So take the next question instead. What is the 10th power of 2 (two to the tenth)? The answer is simple and straight forward: 1024.

We developers live and operate on the binary system since the early stage of our software engineering career. The base-two system is in our nature and we’re very familiar with that. That’s a good thing, while you enter on a very deep waters of estimation.

Small, Medium, Large scale with Story Points values

The Small, Medium, Large scale is generally accused of not being able to produce the velocity. People also rise a concern that the scale is not giving you a feedback on how those tasks are handled within sprints.

Here’s the best solution I have found so far. Assign 1 to Small tasks, 2 to Medium ones, and 4 to Large stories. Why four not three? Here’s an answer: 2 small tasks equals one medium task (1 * 2 = 2), two medium tasks should be equal to one large task, hence the value of four (2 * 2 = 4). From now on, if you use Small, Medium, Large estimation scale you might calculate the velocity of you team and capacity for the next sprint.


For quick estimating your backlog I suggest to use a 1000 Story Point value to tasks that are larger than one day of work. Why not 1024? When you have a list of tasks 1, 2, 4, 1, 4, 2, 1 and so on, you might be able to quickly estimate how big is your backlog. When you add a 1000, this number stands of the other values and with 1015 story points total in backlog you’ll be able to tell that there is one unestimated task and the other sum-up to 15 story points in total.

The situation is a bit harder when you use 1024 as a numeric substitute for too big value. 1039 does not give you a straight forward information about backlog total story points.

Why not 100? Because your backlog is likely to grow and sum-up to hundreds of story points. In this case 117 would give you two possibilities: either your stories add to 117 or you have one 100 point task and few others that calculates up to 17.

With very large backlog you might want to use even bigger values like 10.000!

At the other hand 0 is a very tempting value (it does not have a side effect on backlog), however you might find it hard to distinguish this story from the other ones if you put such story in your sprintlog by mistake.

No value at all is the thing that I am experimenting with, although it have a problem with double meaning whether an issue is not estimated or just too big.

Monday, February 10, 2014

Product Owner Checklist

Crosspost from:

Product Owner Checklist

This brief checklist helps you remember the most important things to become a good Product Owner.

As the Product Owner you are responsible for maximizing the value of the product and the work of the Development Team. Your way of doing this may vary across organizations, Scrum Teams, and individuals. This checklist is therefore only an example.

Even the best Product Owners cannot know beforehand what is most valuable for the customers, end users, and investors. Thankfully, Scrum’s inspection and adaptation cycle provides feedback and learning opportunities also for you as the Product Owner. To monitor your personal growth, you can occasionally re-check your Product Owner Score.

Click here to download the Product Owner Checklist. You can comment it below.

Monday, February 3, 2014

Scrum, but -

Scrum jest najbardziej rozpowszechnioną zwinną metodyką wytwarzania oprogramowania. De facto stał się standardem w projektach IT.

Oto krótka prezentacja ukazująca najczęściej popełniane błędy podczas pracy zespołów.

Sunday, February 2, 2014

Self-Organization: The Secret Sauce for Improving your Scrum team

High performance depends on the self-organizing capability of teams. Understanding how this works and how to avoid destroying self-organization is a challenge. Until you understand complex adaptive systems and how Toyota works it is difficult to improve team velocity. Jeff will discuss three core topics:

1. Shock therapy as a strategy for booting up teams.
2. The Cosmic Stopping Problem, otherwise known as the choice uncertainty principle.
3. Punctuated equilibrium - how software systems evolve

Take advantage of these concepts and you may find a way to achieve the ultimate potential of a team. This session will be a "Deep Agile" presentation keying off topics presented to engineers at MIT.

Speaker: Jeff Sutherland
Dr. Jeff Sutherland is one of the co-creators of the Scrum software development process. He and Ken Schwaber invented Scrum in 1993. Since then he has worked with many software companies and IT organizations to extend and enhance this process.

Sunday, January 26, 2014

The Seven Deadly Sins of Agile Measurement

Using metrics as levers to change someone else's behavior is sin #1. Rather, they should be used to improve your own performance.

This is recording of a reprise of this talk that I gave in Raleigh, NC in November, 2013. The original talk was voted the best talk of the Agile 2013 conference.