About Matthias Seul

Matthias Seul is a Development Manager, Agile Practitioner and Master Inventor at IBM Security. He is also a PMI-ACP, SAFe Agilist, CSP, CSM, CSPO and LEGO Serious Play Facilitator. Matthias started with Agile and Scrum in February 2010 and has since then worked as a regular Scrum team member as well as a Scrum Master and team coach. His experiences are backed by over ten years of working in the IT Security industry, collaborating both international and multi-cultural on a diverse selection of projects and products. Since Mid-2010 Matthias has transitioned away from the Software Developer role and become a full-time Scrum Master for all teams in the Kassel lab. As Scrum is the preferred development methodology this role places him front-and-center for the facilitation and support of all projects He is currently leading as well as coaching multiple teams to deliver customer value as well as project success working with team members, technical leads, architects, product owners and project managers to ensure goal focus. Having received formal project management training as well as an education in Economics Matthias can integrate both deep development experience and business insight in his day-to-day work. Matthias believes that Agile and Scrum are an effective means to integrate the ever-changing business world with value-driven software development efforts.

On Co-Location

Having worked in a few distributed teams my experience has been that  with large disparate time zones, with people either getting up very early or having to stay in very late, working together can be very painful.

From my perspective working on complex, emergent solutions that require a lot of communication and free expression being co-located is the most conductive and least inhibiting way to work. Sure, on paper there are technical solutions for pretty much everything, though there is one thing they did not solve: Human nature.

From what I know Humans are “designed” to work best in direct interaction. Expressing, finding, establishing and maintaining shared values and a unified vision is something that has shown, at least for me, to be very time-consuming and costly trying to do it remotely.
Especially if you’re working with a new team the issues of trust, prejudices, fear of looking stupid and general unease can take weeks and months to be resolved, if they can be resolved at all.

I’ve been working with people remotely and had – despite honest efforts – severe communication and alignment problems. Then we finally met for a week of working co-located. And suddenly it clicked. It was the actual closeness, the direct face-to-face communication that broke barriers and tore down (hidden) misunderstandings that had been existent for months.

I look at current efforts (at least in my division) to co-locate teams and break up distributed structures. I see Design Thinking Workshops that emphasize high-energy, low-friction direct face-to-face interaction. I see the difference in my daily work between remote and co-located teams.

For me this tells me co-location is not a luxury but a necessity to fully unleash teams and employees potential. Companies that are driven by innovation, not lowest-cost, should use co-location as an investment to stay competitive. And I welcome any efforts towards this goal.

Breaking News: Team Members are Humans.


I’ve recently attended an instance of a virtual training course on interviewing job candidates. While the course and trainer were great – make no mistake here! – there was one thing that made go ballistic.

While portaying the benefits of the specific interviewing approach, about 5 slides in, the “Utilization Rate” was named as one of the most important metrics of a successful hire.

Come again?!

I’ve then asked what “Utilization Rate” meant and it was exactly as I feared:
The amount a hired person was being busy on a given project.

Utilization is good for machines

Coming from regular business education I know that a lot of traditional management practice revolves around making sure resources are used to their maximum efficiency.

After all if you pay a resource for time you may as well make sure you’re getting the most output in that time.

This works well on the factory floor. With machines.

If you are renting, let’s say, a assembly robot, for a rate of 1000$/day flat you better make sure that robot is assembling like hell distributing the fixed cost over more pieces produced.

This theory worked well there so why not transfer it into the office?

People are not machines

The difference with people is that people are not machines.

People are not steady in their output, not do they perform the same under 50% workload as they do under 90% workload.

If you look at the concept of “Slack time” this describes that when doing time management you should always have more than 20% of buffer available for dealing with interruptions, unplanned work or plain socializaton.

People with near 100% utilization are very rigid in their schedule and unable to cope with rapidly changing requirements. They also become robot-like having zero time for their colleagues, which actually hinders them in getting things done, as the informal (social) networks are oftentimes the key differentiator between someone who could and someone who can.

Looking at other literature, for example “Focus” by Daniel Goleman, a key factor in creative, breakthrough thinking is the ability to be able to control the flow of your work including time with no specific commitments.

Furthermore  – looking into all the learning and community initiatives – all of those make you  more connected, knowledgeable and ultimately a happier person. When should you do all this if you are near 100% utilized? In your off-hours?

Keeping skills and networks active and cultivated makes sure that people that are effective today will STAY effective tomorrow.

Truth be told – going for high utilization will give you better results in the short term. But with our rapidly changing world constant investment must be made in education and personal development.

With near 100% utilization there is no time to make that happen. In the long term this will mean that any “resource” will become less effective and fast.


Why even care for utilization?

I believe it comes from the thinking that a manager has to know that everyone is busy. But why would that be necessary?

Looks like classical Theory X thinking:


Image stolen from: https://en.wikipedia.org/wiki/Theory_X_and_Theory_Y

If you assume your workforce is made up by Theory X people you have to assume people will try to trick you as soon as an opportunity presents itself. That would require a lot of command & control because you cannot trust a Theory X person.

 Fortunately no human being is a Theory X person.

All human beings are Theory Y people, striving for purpose in life, trying to get enjoyment and fulfilment in what they do.

Don’t believe me? Read “Drive” from Dan Pink or “Start with Why” by Simon Sinek.

So how come some people act like Theory X? It’s mainly because their environment drives them to do so. Because they are incentivized to act like Theory X.

Think about it. If the environment assumes you are a Theory X and you are evaluated and measured by utilization, what would you do?

You would do what gives you the most benefit in the given environment – thus you make sure you are looking as utilized as possible.

If you are a motivated worker you may even do a great job DESPITE of the environment (or try to change the environment, but that’s a different story).

Getting to Y

Looking at the things that exemplify a Theory Y person it looks like this is the person you would want to work with.

So how do you get there? Easy. It’s all about trust.

“Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done. ”

– Principles behind the Agile Manifesto (http://www.agilemanifesto.org/principles.html)

Trust is central to Agility.

You have so many talented people in your teams. People with rich experiences, a large inventory of education and perhaps even a healthy amount of humor.

How come you trust these people to arrive at work every day, navigating 66% of the rest of their life on their own, but as soon as they have entered the office floor you treat them like unreliable, greedy, selfish idiots that need constant supervision?

You already have the team you need to get the job done.

Trust in their ability to solve the issues in your project. Give them the freedom to act without having to come to you for approvals constantly.

Establish an understanding of and and agreement on the goals and why they are worth achieving and the rest will come  naturally.

Measure by Results

In the end it does not matter that everybody was very busy on your project. It does not matter that you can show that all of your resources were 98% utilized.

The only thing that matters is what the project can deliver and if the results are what the client & business need.

That is why in Agile we have empowered teams that focus on goal attainment while the manager steps back. That is why we focus on servant leadership to ENABLE all of the workforce to do the best they can.

  • Establish goals that are worth attaining.
  • Explain the why and listen for questions and new perspectives you might have missed.
  • Create a shared understanding and agreement of the road ahead.
  • Get the heck out of the way.
  • Be available and open to answer questions on the way and help out if someone is in trouble.
  • Trust your team to get the job done, because they will.

People are not things. Don’t treat them like things.

Opinion: What Makes a Scrum Master an Effective One?


I’ve recently been asked:

“Would you have any pointers to any internal or external information you recommend on guiding/teaching scrum masters on how to be an effective one?”

This very straightforward question actually has a complex answer.

The main cause for this is that the role of the Scrum Master is, intentionally, not something that you can map to some of existing clear-cut roles of Project Manager, Team Lead, (People) Manager. It also has some restrictions that are required to keep the role effective.

So before I delve into dishing out recommendations, I first want to deconstruct the role that is a “Scrum Master” from my first-hand experience and point-of-view.


As said before the Scrum Master role is a hybrid. It has been intentionally crafted from different pieces of other roles and received new responsibilites. As such many people, especially if they transition from traditional roles (e.g. as a Project Manager) struggle. I’ve seen quite a few attempts at “mapping” existing processes and behaviors to the new role. My take is, if you actually “succeed” in doing that, you miss out on the chance of a profound change in the way you work and thus forfeit many if not all of the benefits this brings.

So with that in mind let’s not try to see what role is similar to a Scrum Master or how you can best map your existing stuff – let’s take a look what a Scrum Master, in my opinion, should focus on.


The Scrum Master’s responsibilites are broken up among three areas, all in equal measure.

1. Process

Knowledge and application of Scrum within the Agile Mindset. Understanding the different elements and artifacts, why they have been created and where to apply them.

2. Coaching

Enabling others to understand and implement the Agile Mindset. Understanding their issues and offering support in resolving them. Helping the team and stakeholders to achieve mastery in their craft.

3. Leadership

Offering guidance and a clear vision where needed. Ensuring organizational alignment across all levels. Establishing and maintaining communication between involved parties. Creating transparency where ever possible.

Beyond Process Ownership

The first thing that might be surprising is that the responsiblities go beyond pure “Process Ownership”. Although the Scrum Master is usually introduced as a role to whip the team an stakeholders into shape the role needs to quickly transcent that singular focus if to be able to unleash to the team’s full potential.

Just owning the process alone but not being able to foster understanding in the “Why” and communicating the results will just lead to people blindly following it “because Scrum says so”. How will you ever achive wide acceptance or continuous improvement if nobody gets why you are actually going Agile (Leadership) and addressing their concerns (Coaching)?

Providing Coaching without knowing the process can cause you to miss the realities of the business and denies you the tools to model the day-to-day work (Process). Also if people do not follow your leadership why would you even make suggestions (Leadership)?

Finally assuming leadership is not something reserved for those carrying a “Manager” title. Everybody can take up leadership if the cause is worthy and the time is right. That said a Scrum Master is the embodiment of a “Servant Leader” – working not to order people around but to offer assistance and then get out of the way as quickly as possible. To provide leadership you need to understand the issues people are facing (Coaching) and have the right tools to offer solutions (Process).

In the end it all comes together to form a whole, rounded role that goes way beyond Process Ownership.

No Discliplinary Power

In my opinion the Scrum Master cannot be someone with disciplinary power over the team members.

The Scrum Master can also not (asked to) be part of the performance review process for team members.


The Scrum Master’s goal is to unleash the power of the team. To that end the Scrum Master must work on neutral grounds and the principle of confidentiality when talking to to team members, especially on touchy subjects.

Sometimes team members may be hesitant to name issues openly if it concerns their work, mistakes or other people – especially if the person they are talking to is supposed to hand out their performance rating at the end of the year.

A first-line manager cannot be a Scrum Master. Avoid this at all cost.

No Part-Time Job

If you look back up at the three responsibilities you see topics that are as vast and diverse as can be. Many companies today are hiring people for full-time Scrum Master jobs.

And for a good reason: It is a full-time job.

To enable a Scrum Master to actually be able to fill out all of these responsibilities the time has to be available to do so.

Just adding Scrum Master responsibilities to an existing “Developer” or “Lead Developer” role might sound obvious but is also wrong.

The dual role automatically creates a conflict on time allocation starving both roles for focus and attention. With the constant context switches and lack of depth you will not see a 50:50 split – rather something along the lines of 20% and 20% is more realistic. Around 60% will be getting lost because of interruptions and the person becoming quickly overburndoned and entering a purely reactive state, working down the ever-increasing stack of “stuff to do”.

This not only increases stress but also a creates a liability for the team and the business as both cannot rely on the person to both deliver the development and Scrum Master commitments.

If you want somebody to become a Scrum Master make it a full-time job.

Also: A good Scrum Master can handle two teams. An excellent Scrum Master can handle one team.

Mindfulness Required

Just as the Scrum Master is not just a Process Owner the person owning the role is not just an employee – we’re (thankfully!) working with human beings. And this requires a surprising knowledge of the human self.

Mindfulness is a broad topic oftentimes stretched to cover different areas of conscious behavior, recognition of (inner) body signs, empathy and vision.

For me mindfulness starts at the self – recognizing that you are more than just your intellect and logic. Accepting that your emotions and instincts are not something to be turned-off or pushed away. And finally listening closely to what your body is very subtly trying to tell you. If that sounds like new-age feel-good mumbo-jumbo… well, let me tell you that ignoring all of this for too long could lead to you being at an all-time high stress level until you suddenly get nosebleeds in meetings and almost collapse from exhaustion. All the while being completely confused why you are all-time angry and your damned body refuses to play along.

This is not a place you want to go. Ever.

The problem with a lot of that is many people – including me – have learned to suppress their needs over so many years that the natural signals are no longer properly recognized or automatically subdued. This is not a process that happens in a few weeks or months. It takes years to manifest – or “learn” – until it has become a state that feels completely “natural”.

A Scrum Master being lodged in between many parties and having to negotiate sometimes really tough topics needs to have a lot of mental and physical buffer to take almost anything with a degree of calm and professionalism. This calmness cannot be enforced or upheld by pure will. It is something that requires the Scrum Master to ensure regular de-compression from stress and work-related pressures.

To do be able to achieve this state is is neccessary to properly and honestly understand where one currently is. How stressed am I really? What do I REALLY need now? What is my body REALLY needing now?

This requires careful approach, reflection and – especially – time.

This creates a shared responsibility both for the Scrum Master to establish practices for Mindfulness as well as the surrounding business to give the space to do so.

Failing to do so could jeopardize entire teams by subjecting them to overworked, stressed-out Scrum Masters.

It’s About Succeeding Better

You might have heard of other projects that did things that I have recommended against and still were considered successful. And I have no doubt that they were successes.

But have you ever asked yourself it there is only a binary state of Success/Failure or if there are degrees?

What if the projects you heard of where successful with only 20% of their potential realized? Where would the projects be now if they could have realized 50% or even 70% of their potential?

To come full circle with the initial question about become more effective a lot of the options here are not about “just” succeeding.

They are about Succeeding Better.

I invite you to try them out for yourself and let me know in the comments or via email how it went for you.

Further Information

Process Knowledge

Essential Scrum by Kenneth Rubin

Agile Retrospectives by Derby et al.


Coaching Agile Teams by Lyssa Adkins

Start With Why by Simon Sinek

Drive by Dan Pink


The Humble Inquiry by Edgar Schein

Influencer by Grenny et al.

On Project Success – Why Traditional KPIs are not enough


Something is amiss in Project Management Land and it’s not the usual “Traditional PM vs. Agile PM” squabble. It’s a lot more fundamental as it goes to the core of every project:

The measure of success.

This is different from the question of goal attainment, a topic which in my opinion has been examined from a lot of different angles and can be measured to a satisfactory degree, from the very basic following the SMART / INVEST criteria to fully-fledged project scorecards. No – this is not about goal attainment, it’s about finding out if we’re are targeting the correct goal in the first place.

“A major cause of the disconnect between completion and success of strategic projects is that most PMOs still rely on the same old metrics as a proxy for success:
Operational measures such as on-time and on-budget, and stakeholder satisfaction.”
– Matt McWha, CEB IT Quarterly Q3 2014


“We’re all familiar with the phrase “what gets measured gets done,” but what if we’re measuring the wrong things?”

– Andrew Horne, The IT Scorecard Disconnect, How Metrics Can Derail Your Strategy

Could it be that over the years we have become utterly efficient at checking for goal attainment and lost contact to WHY we’re actually pursuing  these goals?

The Curse of Tradition

Looking at traditional project what’s getting measured? We usually check if:

  • We were within or below budget
  • Met the project dates & milestones
  • Met the quality requirements

Tick the checkbox next to each of these requirements and the project is golden and we can move on to the next task. If only it were that simple.

Traditional KPIs usually miss one central aspect: Short and long term contribution of the project to business success.

Not true you say? Well tell me – when does a project end? Does it end when the delivery is complete? When the customer has paid?

What about long-term effects such as market share? Reputation? Or even more down-to-earth things as ongoing maintenance / support costs?

All of these effects contribute to a business’ success but very few projects are monitored beyond the hand-off to the customer – and even if they are it’s usually with the wrong metrics or the wrong intentions.

100 PMs were asked about project success…
70% cannot adequately quantify project success
38% report overly positive results to secure future funding
80% analyze / review completed projects inadequately (*)
(*) Due to focus on classic KPIs such as delivery date, cost, quality metrics – not on business results
– John Ward. „Delivering value from IS and IT investments“, Cranfield School of Management, 2006

Long-Term Effects

All of these issues create the problem of a business closing off projects one-by-one but ultimately stumbling towards doom.

What we need is not blindly following a plan but an examination of long-term effects on the business. This requires new KPIs such as:

  • Project Fit with Customer’s Needs at Time of Delivery
    Delivery is not about what the customer wanted twelve months ago but is needed now.
    On average 33% of all requirements change within 12 months. Was the project able to keep up?
  • Effect on Business Reputation
    Did the business reputation bloom or suffer during the project?
    What are the long-term implications on the brand?
  • Development of Turnover Time and Cost for Change Requests
    How fast was the project team able to integrate change requests?
    What was the cost associated with each change?
    What is the trend of the turnover time and cost?
    Did the project team get more efficient over time?
  • Team Knowledge Accumulated and Shared
    What new skills have been brought into the team?
    What is the level of existing skills?
    Has knowledge been transferred between individual team members?
    What new ideas and developments have started as a side-effect to the project?
    What is the long-term implication on the business’ ability to deliver?
  • Ratio of Participation in Innovative Development
    What’s the ratio of projects targeting an innovative market compared to those targeting a saturated market?
    Is the business just treading the ground it already knows or is it pursuing new endeavors?
  • Level of Project Sponsor Engagement
    How did the executive sponsor’s engagement develop during and after the project?
    Where they engaged? Did it seem that they recognize the project’s importance or were they mostly just walking piggy-banks?
    Do the projects align with the corporate vision? (Usually goes hand-in-hand with high sponsor engagement)
  • Market & Mind Share Gained
    What was the effect on the market share of the business? Will it be able to look back on an expanded market share?
    Perhaps by winning over return customers and creating positive word-of-mouth/references?
    Did the new product capture new market share? How did the market share develop over three, six or twelve months?
  • Long-Term Project ROI
    Was the project actually worth the investment?
    This is not just adding up costs and comparing with project income – it’s also about measuring the impact on future business.
    Did the project drive the customer away or did it actually increase the prospects of new contracts?
    Who said that the project will only pay out once?

Agile Performance Measurement

The Problem of Measurement

As more and more projects shift to the Agile methodology more focus is put on the entire team’s performance and delivery. This in turn means it does no longer matter if you as an individual have completed all your assigned tasks if the team as a whole has failed to succeed. While the approach of “we’re in this together” is definitely a large step forward when delivering value and results it becomes problematic when managers are required to do individual performance assessments of each team member.

While I do not have the perfect solution I want to give some insight in my personal experiences and opinions on this topic.

There is no Team in I

The main problem with the situation is that Agile promotes “one team” thinking which is tremendously beneficial to the performance and success of a project. On the other hand high-performers want – and to some degree – deserve to be recognized for outstanding work. The issue of if and how to reward individuals in a team environment is a tough cookie on it’s own that I’ll skip in this context.

What I do want to emphasize is that in an Agile environment the individual rating of team members is made even tougher as you technically need to separate the contributions to the team result. Also the question comes up: “If I emphasize team results and team achievements, what do I set up as hard, measurable success criteria in the Performance Assessment?”.

For both questions there is no ideal, one-size-fits-all, silver-bullet solution. But there is perhaps a way to be both Agile and be able to recognize performance fairly.

Hard Facts for Everyone

When it comes to hard, measurable business results I would always recommend to do this on a team level. This means goals like release dates, quality metrics, X amount of leads converted into contracts, etc. should always be defined for the entire team. These global goals then go into each team members’ Performance Assessment goals. The important part is that everyone on the team has to have the same shared goals. It’s not okay to cherry-pick or let team members choose their own selection.

If you cannot define goals that can be applied to the entire team then it might be worth investigating why people with widely differing goals are put together as a “team”.

It might be preferable to openly discuss and define these goals in the entire team so that everyone can contribute. In the end it’s important that every team member can commit to the shared goals and be evaluated by them.

Using this technique you can enforce the “one team” spirit while at the same time laying hard ground rules for evaluation.

Going Soft

It’s pretty obvious that successful project work is a lot more than just following a set of defined, measurable goals. It’s also HOW the team approaches new challenges, works together and gets the value delivered.

This touches upon areas such as problem solving skills, inter-personal communication, knowledge-sharing and the general work values. As these things are less easy to define and may differ from the assigned/perceived role of a team member things will get difficult at this point. I would recommend splitting Soft Skills into two groups: General team rules and individual expectation.

The general team rules should encompass how the team approaches a given situation, it’s work ethic and conduct. This includes things like “We will share knowledge” or “We will identify the root cause instead of treating the symptoms”.

If you have defined the general team values when initially creating the team AND WRITTEN THEM DOWN – good job! If not it now would be a good time to have the team define these general values and write them down (e.g. as a poster on the wall) so it is clear HOW the team accomplishes it’s goals and goes about the daily work. You should make it clear that the team will be evaluated on each individuals follow-through on these rules.

It’s important to note that these rules should be a guideline and that it is okay and normal if people are not always 100% or even 80% on track – we’re still humans not machines.

For role-based expectations, e.g. if you have a team lead, architect or someone with a special role on the team you should define the expectations as you would with every personal goal – direct and in private.
As it is clear that these expectations are tied to the individual and the individual’s role this approach does not conflict with the general team rules and you can draw the line more clearly.

Matching Expectations with Reality

When it comes to comparing the expectations with actual results the approach largely depends on what you are evaluating. The hard, measurable team goals can be checked during sprint review and delivery gates. The approach will be more or less the same as with every other business goal. For the “Soft” values and skills things get very different very fast.

Any kind of evaluation of the softer goals requires experiencing how the team acts. This means attendance at the regular team events such as Scrum Meetings and Sprint Reviews is pretty much required. How will you evaluate somebody if you haven’t seem them in action? But by all means do NOT visit the meetings taking notes on each members performance! It’s more about getting a feeling where the strengths and weaknesses are. If you are not directly involved in the project because you are “just” the line manager make sure that you regularly check in with the project manager / product owner involved. Also make sure that the PM/PO understands what criteria you are evaluating team members on so you can get meaningful feedback and not just a general “performance was pretty okay”.

Another tool at your disposal are 360° reviews. These kind of reviews take in feedback from peers, managers, people-managed and the person in question to form a better picture of the performance. If you want to do this make sure you understand how the review process works as it is quite different from the regular manager-evaluates-employee approach and also be open about your intention to use it.

In the end you should be able to combine business results with feedback on the individual’s “softer” values to create an accurate evaluation without counteracting Agile’s spirit of teamwork.

The Model


One Team – One Mission

“Gotta Keep ’em Separated”…. really?

So here you are, setting up your new project. And what do you need? A couple of Devs and then some people doing QA? Right?


 In past many software projects have separated development and QA or “testing” duties into different teams. This trend has been changing over the last few years to have only one team with devs and a couple of QA’ers.
It’s a step forward but we’re still not where we want to be:

 A single, unified team able to take on the different duties as needed.

And here’s why it matters:

1. Goal Orientation

Separating Dev and QA even if it is just by assigning these duties to specific people immediately creates differing goals for these groups. Devs will want to release software, to complete their stories and move on with the next task. Who blocks their progress? The QA’ers or “testers”. The QA’ers on the other hand have the goal of providing test coverage and preventing defective deliveries from being released. So they have to “clean up the devs’ mess” all the time.

Who of these people actually has the unified goal of both RELEASING and having GOOD QUALITY? Usually no-one.

If there is no-one specifically assigned to Dev or QA duty it no longer becomes a matter of coding something or getting it tested – it’s now a team goal to deliver results.
The difference might be subtle but it’s actually quite the game changer.

2. Flexible Assignments

Depending on how a project might progress the Devs might actually deliver new functionality faster than QA can cope with testing coverage. While unit tests should be present given a TDD environment (more on that later) the system and end-to-end tests also need to be done and they can be a huge time-sink. In other cases QA might be comfortable keeping up with the Devs but (or because) they are falling behind in their project plan.

Neither situation is ideal. And instead of having to bring in new staff it’s a lot easier to shift people into different areas as needed.

And this is A LOT easier if no-one clings to a specific position in the first place. That way workload is automatically balanced as needed by the team and project as the overall success (see #1) is a shared goal.

3. Skill Mixture Needed

When looking at test-driven-development it becomes clear that a developer can no longer concentrate on just creating code. A considerable degree of testing knowledge is also needed to provide the necessary (and effective!) test coverage.

When looking at the QA side the times of grinding through a sheet of manual tests is coming to an end. Initiatives such as CI and DevOps mandate fully automated testing from day one. However this testing automation does not magically appear, it requires a lot of coding on the QA-side of things. This requires a considerable degree of programming knowledge.

All things considered a developer can no longer work without testing knowledge and a QA’er needs programming knowledge. Mixing skills and knowledge in a team is therefore absolutely necessary.

The Bottom Line

Modern projects require a team that is aligned with a shared goal – to deliver a high-quality product on-time. Constantly changing needs and requirements make it necessary to be able to shift workloads quickly and flexible without being tied to specific people or teams. And with the TDD/CI requirements of modern DevOps-driven projects the skill separation between Dev and QA has become non-existent.

It’s okay to bring in people with different skills together – but in the end it requires a combined team effort to be successful, not the combination of a few loose parts.

On Magic Estimations


What if you could estimate about 40 Stories in just 10 minutes?
“Impossible!” you say? Well then – read on!

What are estimations really?

They are an attempt to guess what the future will bring based on a multitude of factors such as experience, hard data, gut feelings and the likes. Estimations are also always wrong. How much depends on the subject and the person or group estimating. But nevertheless they give us a valuable guideline and basis to do a conversation.

With that established let’s take a look at Magic Estimation, originally introduced by Boris Gloger on the South African Scrum Gathering.

Idea behind Magic Estimation

As established estimations are usually wrong but a valuable guideline. However time spent on estimations helps do the right things in the right order but does not directly contribute towards the project goal. A team can be very busy for months estimating this and that and not produce a single line of code. Magic Estimation tries to harness the wisdom of the crowd to quickly estimate a large backlog – and by quickly I mean “within minutes”. It therefore reduces the time spent on estimations while retaining their value.


You’ll need a backlog that has stories in a shape that they can be (at least roughly) estimated. Following the “Story Maturity” method described in an earlier article of mine can help you with that. Apart from that you’ll need a team of five to ten people and 15 minutes of time.


  1. Print out all stories (one per piece of paper) or fetch the story cards currently in our backlog – it’s important to use paper. This will not work using a computer.
  2. Shuffle the stories and put them on a stack face-down
  3. Prepare a table where you designate areas to a specific story point. You could start with a “1” area and then go upwards. The idea is that people can place the story cards in that specific area to indicate their estimation
  4. For the next 5 minutes follow steps 5 to 9
  5. Every team member picks up a story from the stack
  6. IN COMPLETE SILENCE quickly skims the story and decides in which area on the story point scale to put it
  8. Whoever placed his/her story picks up a new one from the stack
  9. Repeat until all stories are placed
  10. Write the current estimation on the story paper
  11. IN COMPLETE SILENCE everyone can move any number of stories to a new location (**)
  12. As soon as the story was moved strike-through the prior estimation on the story paper and write the new one down
  13. Do this for 5 minutes
  14. Collect results

(**) As an alternative of moving the stories around you can also shuffle the stories into a new stack and repeat from step 5.

Collecting results

Stories that have only one or two estimates (with one crossed out) on them will retain that estimation for this session.

Stories that have more than two estimates on them will be gathered and need to be looked over, as there seems to be widespread disagreement on the effort required. You can schedule the discussion for a later date or address it directly.

And with that you’re done!

The Bottom Line

Magic Estimation allows you to quickly get estimations for a large stack of backlog items. These estimations are rough – yes – but they will give you a feeling where you are with your project.

They can also trigger a lot of healthy discussions without spending too much time on backlog grooming – giving you more time to work on you project instead of sitting in meetings.