FAST RACE Agile Estimates

The most common concerns around agile estimates are:

  • What are the benefits of Story Points vs Hours?
  • How to estimate and execute fixed triangle projects?
  • How to estimate Sprint to be more accurate and predictable?

Story Points vs Hours

Story Points are turned to be very popular for estimating Product Backlog. Story Points are effective when RACE principles are respected:

  • RELATIVE: Product Backlog items estimated relatively to each other using Fibonacci sequence;
  • ACCURATE: Team continuously refines and break down larger stories into smaller items to increase accuracy;
  • CONSISTENT: “1” Story point meaning established at the beginning and never changing over the time;
  • EMERGENT: Product Backlog is estimated for the next 4-6 months; new items or stories should be estimated.

The benefits of Story Points and RACE is that you can effectively measure velocity of the completed Product Backlog items and apply it to the remaining size of the Product Backlog. With RACE in place Story Points will be reliable for forecasting future release plans.

To demonstrate effectiveness of the Story Points you can try out the Paint the Story Point game.

From the other hand absolute estimates as hours are effective to use at the task level in the Sprint Backlog, keeping in mind FAST principles:

  • FOCUSED: Product Backlog items are decomposed into implementation tasks which are usually one day or less;
  • ABSOLUTE: Absolute units as hours are easy to understand. On the low level it also shows that the team understands how to accomplish the task;
  • SUSTAINABLE: Development Team updates remaining estimates at least once a day and review the progress at the Daily Scrum;
  • TRANSPARENT: Hours can be compared to the current capacity at any day in the Sprint. Sprint Burn-Down chart is very common techqnique for assessing the progress.

FAST indeed explains the benefits of using hours at the implementation task level.

How to plan and estimate fixed triangle projects?

I would like to refer to the article which describes the case study at:

The only thing I could add is that the fixed triangle makes sense for reasonably simple projects. For more complex projects the customer should be ready for change management and revisit triangle variables, at least agile helps change management to be extremely transparent.

How to estimate Scrum Sprint to be more accurate and predictable?

In Scrum Sprint we try to focus a team on how to deliver a value in the most effective way. Estimates can create some pressure to be very focused on the individual tasks rather than on the shared goal of the Sprint. I don’t recommend to rush for predictability and accuracy at the very beginning. Please, find some useful thoughts on estimates at:


Scrum Simulator for Beginners

Some time ago, I summarised the unique experience of delivering one day agile workshop. Unfortunately, I don’t use use this form of the training anymore, but the effectiveness was incredible. I’m pretty sure that I will have another occasion to deliver such simulation one more time.

Agile Simulator – Mechanics

The idea is to bring the team (including potential Product Owner) together and simulate all the Scrum elements using real data (requirements, tasks and goals). Instead of Lego, Paper, Airplanes and Drawings we took a list of 5-10 new product requirements. We created Product Backlog when I facilitated short Product Backlog Refinement sessions to add an estimate, value, description and acceptance criteria, as it is something real. We created Sprint Backlog using physical board with all tiny details, in order to demonstrate the the power of visual radiators. During the Daily Scrum, team was trying to update their tasks as it could be in the real world. We completed with Sprint Review. During the final part we used retrospective techniques to discuss what are the challenges we should think of a little bit ahead.


The benefit of the Scrum simulation workshop is that the team can record a session on the video camera which might be useful to remember some practices and bring them into real life. With experienced trainer and coach the Scrum simulation can make more impact on the beginners than any other form of training.

Best Tools to Develop Soft Skills in Scrum and Agile Development Teams

Following the webinar, in which I presented some tools and techniques to nurture soft skills in agile teams, I have a pleasure to share slides and video.


During the webinar I found some interesting questions which I would like to follow-up:

Q1: Is group responsibility real responsibility? In my experience it rather cause personal irresponsibility.

Responsibility takes place in the group of people when one or more memebers are reacting on the situation. Personal responsibility usually occurs when someone cannot find whom to blame to. How many situations you can remember in  which you was the only one to blame? Last time I was the only one to blame when I had bumped my car into road construction because of the lack of attention – it was clear for me this is purely my mistake – personal irresponsibility, “I need to be more careful next time” – the way how my brains are used to strenghten personal responsibility. Everything else is a group responsibility – it is more REAL than you can imagine. Irresponsibility in software development teams takes place when there is a lack of accountability – no shared working agreements, team members are rather stay in the counter-productive mindstates – blame, justify, shame, obligation, when there is a fear to confront unsatisfaction with the rest of the team, and so on. Five Dysfunctions of the teams and Responsibility Chain can help you to re-think your current experience from the standpoint of the solid studies.

Q2: My team is located in different locations. That’s why we cannot use white board for tracking progress. What you can recomend in this case?

I’m fine to use e-boards. I don’t want to promote any specific tool. I like to use screen sharing, video\voice bridge, Agile e-board, e-pocker planning, collaborative editing tools like Google Drive or so. Someone on the call should play facilitation role and to be completely focused on people and the way they are interacting – in Scrum this is Scrum Master.

Q3: Are there any recommendations how to deal with irresponsible team lead, or even PM?

Awareness should be always the first step to face a problem. Irresponsible behaviour often means that we are expecting some actions from a person but instead we are observing passiveness. Common reasons of the irresponsiveness are: lack of capacity, tireness, unsatisfaction, lack of motivation, fixed mindset, bad habits, lack of soft skills, unsafe environment. In the worst situation all the factors are present in the PM or team lead and this should be addressed one by one. I like to use empathy radar technique to see how I can help the person to increase responsiveness.

Q4: Is it required to document all of the agreements of our team? Should be there a document which can be reffered to when we talking about team aggreements?   

I’m fine to use wiki tools to document working agreements on specific subject areas. Find below the basic set of agreements to be documented if you want to have responsible Scrum Team:

  • Roles and accountabilities agreements
  • Definition of “Done” – process and quality agreements
  • Scrum Process rules agreements
  • Scrum pulse – schedule, meeting inputes\output agreements
  • Code review agreements
  • Continuous Integration agreements
  • Coding standards agreements
  • Team behaviour agreements (in accordance to Scrum values – respect, focus, commitment, courage, openness)
  • Communication agreements (Dev Team -> PO, Dev Team – > Stakeholders, Dev Team -> Users, operations)
  • Meeting ground rules

Some stuff I can post on the walls.

Q5: What if Team is big (more than 10+) ? 

As agile leader and Scrum Master of that team I would teach why 10+ can be risky and uneffective. However the decision how to change team(s) composition in the competence of the Develoipment Team.

Q6: Do you suggest doing retrospective together with the Product owner?

I strongly recommend to do retrospectives with Product Owner as he is a part of the Scrum Team. Ususally Product Owner is one to be balmed by Development Team if he doesn’t present. Common challenges why PO is out of retrospctives:

  1. Language and cultural barriers. Scrum Master have to be aware of this and help to improve cross-cultural, cross-location interactions.
  2. Time zone differences. Because of time zone difference retrospective can went at the beginning of the next day, when PO at 3 a.m. In this case the ground rule should be not discuss issues where PO is involved and follow-up it during the next Sprint.
  3. PO has a lack of time. Scrum Master should work on it and his servant leadership expressed in ability to help PO to find some time for the next Sprint Retrospctive. At the end of the days Product Owner should respect rules and principles of the Scrum framework.

Q7. Is it the job of team leader/Agile leader to organize for white board activities? how often these activities should be carried out?

I like to think of agile leader as a person who is leading by example. Agile environment helps to be aware of what is going on, to stay focused on value and interactions. White boards and other visualizaion in close proximity are very helpful to make interactions effective. If the team doesn’t understand the benefits of visualization my job is to show an example, however I’d rather expect that the team will take over and carry out these activities.


Managing Communication Barriers in Geographically Dispersed Teams

Few week ago I had an amazing time to share my thoughts on how to manage communication barriers in agile teams which are not co-located. In agile development we usually recommend to go with co-located teams as in the most situations it can help to build better cohesion. From economical perspective, co-located teams are cheaper to maintain as they learn faster from each other, performance growth is amplified by better self-accountability. Given all the benefits of the co-location there are still many cases when co-location is impossible. Dispersed team usually consists of engineers from different locations and time zones which cause several inconveniences and communication barriers if we want to adopt Scrum framework and create Scrum Team. On the webinar we were exploring how agile technologies can help us to overcome communication barriers. What are the bad practices we should avoid? How to setup Scrum in geographically dispersed teams? 

You can review it on youtube:

Slides can be taken from:

After the webinar I had some time to answer couple of questions. Let me remind that:

Q: “What is the best setup for daily standups in case of dev team in 2 locations? i.e. big screen + camera + whiteboard (how to make the whiteboard interactive for both locations?)”

A: “Setup can be different. Last time I did it with a Scrum Team from one invetment bank was:

  1. Audio conference bridge with video option (Lync)
  2. Lync screen sharing
  3. JIRA Agile plugin
  4. Lync collaborative boards (similar to
    1. One board Scrum Master is using to capture impediment list
    2. Second board is used to capture general meeting notes
  5. Lync messenger for Planning Pocker
  6. Scrum Master ensure 15 minutes timebox and focuses completely on facilitation
  7. All impediments, new items and tasks are captured to JIRA Sprint Backlog immediately after Daily Scrum
  8. Scrum Master is sharing him MoMs to entire Scrum Team, with updated Burn-down chart, impediments and updated plan for remaining Sprint

In other teams instead of Lync I used WebEx (it has almost the same set of features we needed)

Interactive whiteboards is a nice tool for cross-location design workshops just before the start of the new Sprint”

Q: “If I have BAs, DEVs and QAs, but can colloctace only 2 teams – who is better to sit together”

A: “Who is more connected to produce releasable Increment at the end of the Sprint? Usually, development team memebers with QA and DEV shift have more tasks in the Sprint Backlog,  thus they need more time to communicate and coordinate between each other. Therefore it sounds more reasonable if QA and DEV sit together, shoulder-to-shoulder. BA spends more time on requirements elicitation and usually works up-front to refine Product Backlog. DEV and QA in this case just need an effective tools and good working agreements to communicate to BA”.