The 4 Scrum Masters we don’t want in our team

I read a lot of posts about “what is a good Scrum Master” and thought, these posts are way too positive and friendly.. why not take a more destructive approach and see things from the negative side?

And if you make it to the end of the post, an insightful question awaits. Here goes..

  1. The impatient – A Scrum Master with not patience is like a cat without 9 lives- it just doesn’t work, a Scrum Master will most likely deal with issues that require change, and change my friends – often takes time. So, No Patience – No Scrum Master.
  2. The Self-centered – If all your Scrum Master cares about is how she is perceived, what bonus will she get this quarter and her own well-being, chances are you have selected the wrong person. The Scrum Master supports the team using the team achievement to encourage the team, not yourself you donkey.
  3. The rude – “We don’t need these stupid points to estimate!” i heard a Scrum Master say to her manager, and it does not really matter whether she was right or wrong, the fact is that it is very hard to get someone to cooperate with you when using this approach. A Scrum Master needs to be able to get people to respect and trust each other in order to improve collaboration. Rudeness is not the way.
  4. The self-righteous – Everyone can be wrong sometimes (yes, even me…), but if the Scrum Master considers himself as an “always right kind’a guy”, then Houston – we have a problem”.. Being wrong is part of the role description of the Scrum Master, being wrong allows you and others around you to feel safe to experiment and learn, which a critical element in inspect and adapt – Duh!

I assume that most of your Scrum Masters are not behaving as the post suggests, but my question to you is:
Are you or your Scrum Masters doing anything that even remotely resembles these attributes?

Think about it for a while before you answer. For more, follow me on twitter @eladsof

May the force be with you,

Elad Sofer.

Framework, methodology or mindset?

Who cares? I do! Why?

First,  because it offers an opportunity for a blog post (that increase social media presence, etc.… J), second because some of you are using those words in a wrong way which leads to wrong decisions being made which leads to pain and suffering (more commonly known as poor performance).

I am not trying to find right or wrong answers, or which is better, my aim is just to clarify meaning. Let’s create some order in this confusion.

Mindset

A particular way of thinking: a person’s attitude or set of opinions about something
[Source: Miriam-Webster dictionary]

A mindset is something we believe to be true, which does not mean it is based on faith.
We use the mindset, sometimes unconsciously, when we think (valid only for those who think) and make decisions, a common example is the “fixed vs. growth” mindset, when a person has a fixed mindset they make decisions based on a principle such as “I am who I am, this is what I was born with”. A mindset does not prescribe anything except within a context in which it is tested.

Framework

1. The basic structure of something
2. A set of ideas or facts that provide support for something
3. A supporting structure
[Source: Miriam-Webster dictionary]

A framework is used whenever we need to help something stay in place, be steady and robust, we use a framework for our kitchen cabinets, our car body and they way we work. Just like when writing code, a framework is something we can\should be using in order to increase stability, it is likely to be meaningless unless having something built on top of it.

Methodology

A set of methods, rules, or ideas that are important in a science or art
A particular procedure or set of procedures
[Source: Miriam-Webster dictionary]

A methodology is much more prescriptive and much less context sensitive, it is a set of methods and procedures to be used when facing a certain situation, it is often context specific, and is meant to be applied “as is”.

So which is which?

Not that simple is it? Here is my view:

Agile – while it does not fit 100%, I tend to place Agile more in the mindset category, one of the principles is a bit more prescriptive than I would like them to be (and btw did not stand the test of time for that reason) – “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”, and still it is not even a framework since you cannot really implement it.

Scrum – In my opinion Scrum is really is a 100% framework, it clearly defines the structure needed to be developing products, but offers no advice on what the product development will be, it is meaningless on its own and forces you to make decisions and fit your process inside it. Of course it does not match any process, the same way you cannot properly fit a cabinet door in a car body frame.

LeSS – Large Scale Scrum – is allegedly just like scrum (Based on the LeSS principles) and indeed it is, just like Scrum, not sufficiently complete so that you can take it as is and implement it without making further choices and decisions.

Kanban – Kanban is much simpler than most people think, it is really a very simple methodology that you can implement as is, it is not originated in software and have been applied in many domains. Kanban is very clear and has six rules which dictate how to operate the Kanban System. Hence, Kanban is a methodology.

Lean – This is where it gets tricky, Lean is so much, it a definable multiple framework, mindset, thinking tools, management culture, so I am not sure exactly where to put it, but since it includes so much I am guessing it is all of the above and more…

SAFe – Safe is full of guidance, quote: “It provides comprehensive guidance for work at the enterprise Portfolio, Value Stream, Program, and Team levels”, and while SAFe is referred to as a framework, I would definitely challenge this statement and call it a methodology.

First certified LeSS, (Large Scale Scrum), Israeli training in pictures (and text)

Last week 13 people gathered together with me for 3 days of learning and exploring the Less (Large Scale Scrum) framework. And what a ride it was…

Day 1

We started the journey with describing the roots and history of LeSS and to figure out what the LeSS framework is all about, we then delved into the intriguing 10 principles of the LeSS framework. We experimented with Queuing theory, Lean thinking, System thinking and Causal loop diagrams.

Day 2

On the second day we discussed the meaning of a product, the role of the single Product Owner role, how to deal with really big backlogs, the Definition of Done and the organizational structure that LeSS encourages,
we have also discussed the Role of the ScrumMaster and other supporting structures that are part of the LeSS framework.

Each topic was covered by discussions and exercises.

Day 3

The third day included topics such as working in Sprints, multi-team synchronization and coordination – which we have challenged some of the basic assumptions that many people have with regards to this issue.
We also talked about the technical side of things and even had a demonstration of the TDD development method, and of course the topic of the Sprint Review, Sprint Retrospective and Overall Retrospective.

To close we explored the role of management in a LeSS organization and discussed working in multisite.

Summary

I had a lot of fun and i was able to keep a high level of energy throughout the training, it felt like the participants feel the same.
The biggest challenge was the fact that we had only 3 days… To be able to balance the amount of exercises  and theory and still be able to walk through all major topics is very hard and i am sure that if I had 4 or even 5 days, i could still fill the time with useful topics and discussions.

I want to congratulate the first Israeli Certified LeSS practitioners: Guy Nachimson, Alon Cohen, Ayala Makmel, Ziv Lifshits, Yoel Tahover, Irena Label, Eldad Yehoshafat, Ilan Lifshits, Tal Druyan, Ilan Kirschenbaum, Anat Alon, Orna Shapira, Rony Shapira

If you are interested in joining the next LeSS public training, or you are interested in having a private training in your organization please do not hesitate and contact me or Tal Druyan

May the force be with you.

Yours
Elad Sofer
Certified LeSS Trainer @ Practical Agile

Certified LeSS Practitioner — Why three days?

I often get asked: Why does the certified LeSS Practitioner training require 3 days?
I thought it would be beneficial to write a short post explaining.

I understand the question.

I really do. 3 days for a training is not very common for these types of trainings, partly because during the last years, the Scrum Alliance had set the standard for scrum related trainings for 2 days (See CSM , CSPO).

3 days is more than half a week, which means that we will be gone from the office for most of the week, for some companies & people this seems as a lot and is very difficult to cope with (often due to the large amount of meetings that will be skipped). Still, I think there are good reasons for the 3 days, and I will list and explain them now.

3 days is not so much

It really isn’t.
If we compare it to other trainings besides what the Scrum Alliance has to offer, we find that:

  • PMP Training — 5–8 days
  • TDD training — 3–5 days
  • Cynefin framework training — 2–4 days
  • Agile team work — 2–4 days
  • Agile retrospectives — 1–2 days
  • Testing automation training — 5–8 days
  • Unit testing (Beginner Level) — 1–3 day

So while we got used to a 2-day training as very common for “agile related” stuff, it is actually not very common in other areas so there is no need to feel that something is “wrong” or “strange” about 3 days

Content & Learning pace — The tradeoff.

As an experienced trainer, I can assure you that almost any training can be designed and adapted to different timeboxes. And so can the LeSS training.
However, this is a certified LeSS practitioner training, and as such we aspire that the participants of the training will leave it with a good and deep understanding of the framework after they have invested enough time studying it, performing exercises, asking and answering questions, and embedding the basic rules and principles, for this we don’t want to go too fast (or too slow).
When you participate in the training you will understand this better…

Continuity

Why 3 days in a row? In a “standard” LeSS training I reserve some time at the start of the 2nd and 3rd day for review of the last day to review the previous days and make sure things are clear. Additionally, there is the ability to “pause” if we run out of time and continue the next day.
With 3 days split over 3 weeks I fear that some of the topics will be forgotten, some of the questions will be left unanswered and some of the “glue” between the modules will remain vague.
So there is indeed value in doing the training days “back to back”.

Proof of intent

Adopting the LeSS framework requires a large organizational investment, it will require a deep understanding of systems thinking and investment in education and learning, when an organization or an employee thinks that 3 days is a too large investment in order to learn how to help the organization become more agile, I suspect that the chances of this organization actually succeeding to adopt the LeSS framework are not very high.

The Experiment

While writing this blog post I decided that I am going to run an experiment, I will open a certified LeSS practitioner training that will still be 3 days, and it will be done in a way that the days will be split across 3 weeks, to validate that it is indeed more valuable to our customers (that is you), the price for this training price will be higher than the “standard” certified LeSS practitioner training.

If you are interested in joining either the standard 3 days training or the experiment of the 3 days split across 3 weeks, please drop us a line at info@practical-agile.com or contact me.

Would love to hear \ read your thoughts and comments on this.

Let my people go

*The original name of this post was “Have some focus to spare?” but since Passover is around the corner it seemed nice to use the famous statement made by Charlton Heston(Moses).

Very often when we detect a problem, we have a tendency is to shift attention to the area where the problem is in an attempt to solve it. Just ask my kids if you don’t believe me…
This approach, while sometimes useful, overlooks two very important factors: We have a limited amount of focus to distribute & looking at a problem may make it worse.

 We have a limited amount of focus to distribute

Whenever we make a decision to increase our attention level in a specific area, we will give less attention to other aspects (this happened to me with a burnt cake). In complex systems (and just like my kids, organizations are complex systems) it is really hard to predict where that impact will be and how this will affect the overall.

For example: Let’s say that a manager detects there is a decrease in the quality of the code and decides to pay more attention to that, assuming she is super-busy as all managers are, she will need to put less attention on something else. That something else might be the well-being of the employees, customer satisfaction or even her own well-being.

looking at a problem may make it worse

What we are often overlooking is that there are situations in which the right thing to do in order to solve a problem is reduce focus and attention (did anyone mention kids?). Moreover, one of the causes of the problem we experience is a result of our own focus and attention. An example is much needed for clarification:

As in the previous example, a manager detects that there is a decrease in the quality of the code. Yet, the manager overlooked that the reason for the problem is that, until recently, she was checking the team’s code and pointed out errors, and the team got used that. This, in turn, led to an increase in code quality, which enabled the manager to reduce attention since the code quality was clearly improving.
The attention that the manager put on code quality created a safety net for the team that resulted in them paying less attention to code quality, which led them to shift their own focus to other areas. As soon as the manager paid less attention to the code, its quality was reduced. Again.
The manager immediately realized that she needs to go back to supervising the team’s code quality…. Can you detect the infinite loop here?

In complex systems, the simplistic linear “cause and effect” is almost always wrong and leads us to create “sub-optimization” and wrong actions which leads to unwanted results.

So, what’s the alternative?

One of the alternatives to adding attention is to do the exact opposite. By reducing the focus from a specific area we allow that area to fail (and I realize is not always an option – yet it often is) which motivates us to learn and adapt (except for kids J).
In addition, by “letting go” we gain some focus that we can use in other areas such as reading this blog post and learning about problem solving in complex systems 🙂
So, the next time you detect a problem that you really want to shift focus to, i invite you to make an experiment:

  1. Understand the problem and its causes by examining the history and dynamics of it.
  2. Figure out how risky it is to allow a short term continuation of the problem.
  3. Decide when would be that last responsible moment for a corrective action.
  4. Make the problem visible to the relevant people.
  5. Wait, and use the time and attention you gained to do something important such as learning,
  6. Go to step 1 again.

May the force be with you.

We want pragmatic advice

Agile Change Pragmatism

Prgamatism: a reasonable and logical way of doing things or of thinking about problems that is based on dealing with specific situations instead of on ideas and theories [merriam-webster Dictionary]

In my role as an agile coach i often get to meet people and organizations that are considering embarking on their journey towards organizational agility, more often than not these people are seeking a coach that will offer them what they refer to as “pragmatic advice”, they are seeking advice and ideas that are not religious or theoretical, advice that will work it their own company with its own limitations and realities.

 What are they really looking for?

Often they are actually looking for someone that will help them increase organizational agility in a way that doesn’t really change anything, they are looking for advice on how to maintain the existing status quo. Unfortunately often that is not possible.

Can we change without change?

“If you want to change something, it usually requires that you change something” [Elad Sofer 2016]

If the organization want to increase their agility, it probably means that the ways things are at the moment are not producing enough agility, which leads us to the strange conclusion that in order to improve from where we are now, some changes will be required.
In the past, when i was an inexperienced agile coach, i would probably go along and agree to introducing the agile mindset to an organization without significant changes. But not anymore.
My experience tell me that in order to improve business agility, more often than not, major changes are required. Why? Because the reasons for not being agile enough are often embedded in the dynamics of the organization, in the organizational structure, in the ways roles are defined (or not defined), in its culture and more…

Here is an example:

Organization representatives: We want to be more agile, we want to empower our employees, but we want it to be done in a way that does not change the current structure and roles, we are not willing to eliminate the role of the team leader.
Me: Well… than you are not willing to change what is needed. Is there a way for you to reconsider this statement, can we discuss this at all?
Organization representatives: No.
Me: In that case, I am sorry but i fear that the change you are looking for is not really a change. I can’t help you.

Don’t get me wrong

I don’t expect anyone to simply buy-in into someone else’s ideas without questioning them, the opposite is true. I expect to be challenged, i encourage my customers to think and come up with their own solutions to the challenges they are facing, and i also expect them to be committed to real change and not just to be scratching the surface.

Because i want to be pragmatic as well

I want my customers to be happy, which to me means i want my customers to gain real tangible benefits from their agile transition effort and our mutual work, and my experience tells me that there are some things that have a very slight chance of providing benefits, there are also some things that if the organization is not willing to at least try and experiment with, are often evidence that the organization is not yet ready to start their agile journey.
So here is some pragmatic advice.

If you are not willing to consider:

  • Create cross-functional, long-lived, self organizing teams.
  • Eliminate the TL role.
  • Encourage collaboration and reduce (or eliminate) any synchronizing role (i.e. Project manager)
  • Adopt MVP (minimum viable product) thinking.
  • Invest in continuous improvement and long-term thinking.
  • Have business people and developers work together.

There is a good chance you will not even come close to the benefits you can gain from Agile.
This is one the main reasons i find the LeSS framework to be providing very good guidance on large scale adoptions, LeSS, while being as non-prescriptive as we can, still makes sure that the pragmatic stuff are there from day 1.

I would be happy to meet and explain why i find this advice pragmatic.
May the force be with you,
Elad

Scaling – The lean and agile approach

When learning about the SAFe methodology one might come to a conclusion that in order to achieve agility in large organizations there is a need to add roles, artifacts, processes, etc. Recently the SAFe institute even published the “SAFe essentials” trying to answer the question “What is the minimum subset of practices beyond which SAFe isn’t safe?” and feel free to read it yourself and judge. I would say that the list is far from being minimal.

The common reasoning behind this approach is that the bigger the organization is, the more complex it becomes to effectively align the entire organization towards a shared goal.

And indeed it is hard. Very hard. And complex.

Based on my understanding SAFe suggest a solution that is based on the assumption that if something is difficult, we need to have a pre-defined role or process to make sure that the problem is being addressed. Even before we have encountered the problem.
For some, this is indeed a valid approach, however it is not lean, definitely not agile and it goes against the basics of systems thinking.
Below are a few examples to make my point.

Why is SAFe not Lean enough?

Let’s go back in time to the year 1911: This is the year when fredrick taylor coined the term “scientific management”. This theory is targeted at increasing organization’s effectiveness assuming (amongst other ideas) that in order to maximize the potential of the organization, the managers need to focus on planning and decision making, while the “regular” employees need to focus on performing their tasks efficiently.
At the time this theory probably made a lot of sense and resulted in more effective organizations. It is important to notice that at the time, most organizations were lo-tech, assembly line type of organizations in which many of the employees were ignorant, lacked proper education and basic skills. Luckily we are now at 2016.

Toyota, the originator of the lean approach, states that there are two pillars that hold the entire lean structure: “Continuous improvement” and “respect for people”.
Let’s examine the “respect for people” pillar: it means for example that teams and individuals are encouraged to design and use their own practices and processes in order to deliver high quality results. This concept is also reflected in the agile manifesto’s first value – “Individual and interactions over processes and tools”.

What SAFe chose to do is to have a fair amount of pre-defined processes and roles.
In my opinion this is not only disrespectful and undermines people’s ability to design and control their own work, it also clearly goes against the lean concept of Kaizen, and one of its practices which is eliminating waste and specifically over-burden waste and over-processing waste. (see types of waste)

So. SAFe is not lean enough.

Why is SAFe not Agile enough?

Let’s examine principle number 1 from the agile manifesto “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.
Given that this is indeed our highest priority, why would we ever prescribe in any agile framework a mechanism aimed at optimizing inter-team technical integration?
Why would we prescribe at least 2 dedicated roles that supervise (the guide uses the word facilitate – but give me a break…) this integration work?

Here is a nice example: One of the responsibilities of the RTE (SAFe’s Release train engineer) is to “provide input on resourcing to address critical bottlenecks”, what does that lead us to think?
That resourcing is the typical way of overcoming bottlenecks? (Hint: the answer is no) Even more troubling is that this person(s) is by definition a bottleneck. How could that person overcome herself?

Principle no. 4 of the agile manifesto claims that “Business people and developers must work together daily throughout the project”. Well how does that work in SAFe exactly? based on what i read, each team has a backlog, and a product owner, which is not the “business people”, it is a team member that is responsible for prioritizing the backlog?! In addition we have the product managers which are responsible for identifying the customer needs but does not seem to have the ability to collaborate with the teams. I could not find any statement in the SAFe guide about teams actually working with the customer 🙁

Principle no. 9 encourages us to use simplicity whenever possible, and SAFe… well….

So. SAFe is not Agile enough.

Why do i think LeSS is preferable?

Primarily because LeSS assumes less, it is leaner and thinner and encourages the organization to think more, to experiment and to build a solution that is focused on the big picture and is found empirically suitable for the specific realities and challenges this specific organization has.
This means that organizations that decide to adopt the LeSS framework demonstrate real commitment, buy-in and attention to doing so, which are anyway prerequisites for succeeding with a large scale agility endeavor. Adopting a prescribed solution in a complex environment is simply not good enough.

I am not trying to claim that LeSS framework is the silver bullet or even anything remotely similar to that.
LeSS (just like Scrum btw) tries to find the balance between a defined framework and contextual practices while remaining lean and agile, focusing on principles and experimentation.

So after implementing LeSS, will the organization stop using “quick fixes” to solve systematic issues?
Probably not. Yet these will not be “supported” by the framework, and until solving them for real, the framework will surface those quick fixes and the problems they create so they echo. They will keep bothering us as a reminder that the problems that these quick fixes are meant to overcome need to be addressed at their root.

I would like to invite you to learn more about LeSS, either in one of our upcoming “certified LeSS practitioner” training or in other places.

As always: May the force be with you.

Noam Zweig – Head of Engineering Division at CyberArk, Head of Architecture

CyberArk R&D and me work with Lior for already 2 years, and more ahead. For the past 2 years, Lior and his team guided us, and helped us to understand the importance of automation. But besides changing our mindset, Lior also helped us to guide and implement the ideas of automation, TDD, etc… in our development teams.

Lior comes with an open mind, and sharp eyes. He learns really quickly, analyze the pains, and recommend. He has a high-level conceptual understanding of Agile, but he is also technically, and capable of bringing the technical aspects that serve the conceptual ideas.

Lior and his team presented a very professional and open approach and managed to contribute and touch most of our teams.

Lior grooms the long term relations, and push to understand where and how he can help us to be even better.

Also, Lior is actively working to join us in the Agile community.

I think, that if you look for someone that will help you to understand what to do, but later will also help you to implement – but – in open and sharp mind – Practical Agile and Lior are for you.

Product Owner – The Good, the Bad and the Ugly

I’ve had this thought for a while now of demonstrating how can people and organizations deal with everyday situations and present an analysis of them based on my personal views, while some might find this judgmental, others may find this an interesting reflection of their behavior and explore alternatives.

For the sake of the following scenarios I will assume that we are discussing a Large Scale Scrum product, 6 feature teams, one product owner (That is you!)

Situation 1:

You have just realized that the product is behind schedule.

  • The Good: You meet with representatives from all teams and try to see if there is a way to re-prioritize the backlog in a way that will allow meeting customer needs within the deadline, in case this option does not work well, you try and collaborate with the customer to reach a solution that works for both sides.
  • The Bad: You add more developers (you may mistakenly call them resources) in order to finish on time. You won’t. You have obviously haven’t read “The mythical man month”.
  • The Ugly: You instruct the teams “to do whatever it takes in order to meet the deadline”, the team in return will probably cut quality, have lower motivation and trust, and will over-estimate the features next time.

Situation 2:

It is sprint review, a team was not able to get any of their items to Done and hence did not present anything.

  • The good: You ask the team if there is anything you can do to help. You appreciate them for the honesty and for the fact they were not willing to sacrifice quality or paint a false picture. This conveys the right message to the teams and will encourage transparency. By offering help and avoiding blame you also help build and maintain trust with the teams. Following the meeting you talk to the team to find out more details.
  • The bad: You ignore it (e.g. you say “Never mind”) and hope that everything will be better the next sprint. Your intentions are probably good, but by ignoring this situation you may be sending the message that it is ok for a team to show nothing at the end of the sprint. It is not.
  • The ugly: With the presence of all other teams (it is sprint review…) you show how frustrated you are with the team, you ask blaming questions (mostly starting with ‘why’), making disrespectful statements and comparisons such as “You should really learn from team X”. This will backfire.

Situation 3:

It is sprint review, a team demonstrates feature and you find it was not developed to meet customer needs (maybe there’s a bug, maybe it is misimplemented)

  • The Good: You explain that this is not what you the customer needs, You either ask the team to make the required modifications and show it again in the next sprint review meeting, or keep it as is and ignore this PBI when calculating velocity.
  • The bad: You explain that this is not exactly what customer needs, you review the gaps, in order to give the team credit for the effort, you either add another PBI or split the one in question into two, you add the “correct” part of the PBI into the velocity calculation.
  • The Ugly: You see the problem and ignore it. You don’t want to hurt the team’s feelings, you make sure it is somehow fixed in an “under the counter” manner, possibly by another team or one of the team members.

Situation 4:

It is the middle of the sprint, you are observing the daily meeting of one of the teams, it seems that the team is behind the planned schedule and will not be able to complete everything they planned for, you also notice that there are currently 4 PBIs that are in progress.

  • The Good: You wait patiently until the daily meeting is over, if the team did not discuss this issue themselves you share your observations with the team and Scrum Master, you may also offer help and avoid telling the team what to do. You make sure to remember this and raise this in the retrospective.
  • The Bad: You interrupt the daily, you ask specific team members about the status of their tasks, you make suggestions and offer advice without being asked to do so. Possibly you split some of the unfinished PBIs (Product backlog items) so that the part that is not yet done will be a new PBI.
  • The Ugly: You stop the daily and take control over it. You start micromanaging the team in a way that you believe will get them to complete the items they planned for.

Situation 5:

During one of the retrospectives, the team claims that the PBIs are not detailed enough which makes it hard for them to develop them properly, they request that you start writing the PBI in a more detailed manner, possible even write a functional spec for each PBI.

  • The Good: You dig deeper, you and the team perform an analysis of the problem, you try and understand the reasons for the team not able to “fill the gaps” and clarify the details of the requirement on their own. Once the problem is clear, you help the team create experiments for improving the situation.
  • The Bad: You want to help the team so you go back to writing detailed specification, missing the bigger goal which is to get to a state in which the team has  a good business understanding and the ability to communicate directly with the customer in order to clarify the requirements. You have just decided to deploy a “quick fix” for a serious problem which is exactly what you expect the team not to do.
  • The Ugly: You say that you also think that the requirement should be more detailed, but explain that according to the agile coach, this is the way things should work, this is agile and that’s a problem that the team needs to deal with.

I hope you find these situations and their description interesting. Would love to know what you think, whether you have encountered similar situations and how you reacted.

May the force be with you.

#YesEstimates

Effort estimation is a topic that keeps bothering our industry and unfortunately i don’t think we were still able to “nail it”. Perhaps we can’t. Perhaps we don’t need to.
When working with my clients i keep getting questions about the topic, the following post is an unedited version of one of these questions.

I got an email from the CEO of one of my customers, he was inquiring about story point usage and i liked my response so much i decided to share it “as is” with the hope you will find this useful for understanding and explaining the concept.

The original email:

On Thu, Dec 3, 2015 at 3:38 PM, XXXX YYYY <XXXYYY@CCCC.com> wrote:

Elad,

Can you please give me your opinion wether points should be somehow ‘softly’ mapped to time. So when a team is planning, they think about a point is a day… or whatever.

The current situation looks unpredictable.

XXXX

My response:

On Thu, Dec 4, 2015 at 9:12 AM, Elad Sofer <elad@practical-agile.com> wrote:

Dear XXXX,

In my opinion points should not be mapped to days, points are mapped to points only, and when estimating a PBI (product backlog item) we compare it to other PBIs and try to assess wether it is of the same size, bigger or smaller and if so with what ratio.

Points are a measurement of progress:

Using point to measure progress is not the same as measuring time, progress reflects many other parameters such as defects rate, errors in estimation, rate of people being sick, team mood, time spent helping other teams etc…

The way points work for us is that we derive time calculation using the actual empirical data which we call velocity.

Here is an oversimplified example:

Let assume a team estimated several PBIs, and the total of the PBIs is 100 points.

After finishing the first sprint the team was able to complete (meet DoD) PBIs with a a total of 20 points.

We now say the velocity of sprint 1 is 20, so we can assume that based on this data it will require 4 more sprint to finish the remaining 80 points.

Based on past data (and possibly other input), on the 2nd sprint the team planned for 20 points, at the end the team was able to complete PBIs with a a total of 10 points. this can happen for various reasons as explained above.

We now know that the velocity was 10, and that the average velocity is 15, so we can assume we need 5 more sprints to complete the remaining 70 points.

And so on…

So, why do we use this method of estimation?

  • We use points to reflect progress.
  • We use points as a mirror and indicator to know when things may have gone wrong.
  • We use points to simplify estimation and avoid spending too much time on things that deliver relatively low value.

What points should not be used for?

  • We do not use points to evaluate team productivity.
  • We do not use points to evaluate team performance.
  • We do not use points to compare teams.

From my personal experience, once a team (and product) learns how to properly use relative estimation, the predictability increases, at least to the level of the defined DoD.

I hope that answered your question,

Elad