Agility – Page 3 – Factful Agility

There are many arguments about estimating in an agile community. Do we need to use story points, man/hour, ideal man/day, or even #NoEstimation? Today most agile teams are trying to use the story points as the main unit for estimating.

What is the story point?

Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.

When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values? A story that is assigned a 2 should be twice as much as a story that is assigned a 1. It should also be two-thirds of a story that is estimated as 3 story points.

By Mike Cohn

But the main problem is how to assign a story point to an item? This is 5 story points, but how?

Planning poker is dead, Long live Planning Poker

Based on Mike Cohn’s article, Planning Poker is an agile estimating and planning technique that is consensus-based. Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. The values represent the number of story points.

The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time.

The problem is exactly here. “Each estimator privately selects one card to represent his or her estimation”, But in the real world, estimators forget the relativity of points. In my experience, when somebody assigned a 2 story points to an item, He didn’t think to “Oh, It should be two-thirds of a story that is estimated as 3 story points”, Most of the time something goes like this “This is 1 hour for me and maybe 1 hour for front-end developer, so it’s 2 story points.”

As I experienced before, Planning Poker is not an effective technique to assign story points on backlog items, because most of the time development team forget the relativity of story points and story points are useless without relativity.

In the same time, planning poker is an effective planning technique because it helps the team to have a conversation about the story and user’s needs. In the conversation about the story, you will find a new idea or even change the story or….

However Planning is over Plans, Estimating is over Estimations.

Estimation Board

Estimation board is a practice based on my experiences to improve the relativity problem of planning poker technique.

In this practice, you will just add a board (whiteboard or …) to your planning poker process. After estimating any item, you need to put it on your board. Make it visual and transparent.

Something like the following image:

Try to create columns for each category, like the following image:

Keep continue estimation and planning process and update your board:

After finishing estimation, let finalize estimates based on relativity. Let team members check one column each time. For example, there are 3 items in category 2. “Are they the same size?” If not, you can move items to other columns.

This is a simple visualizing practice, but this practice will help you to improve the relativity problem.

Keep relativity all over the project/product lifecycle

You can’t change your estimation touchstone in each sprint. You need to keep this relatively in all over project’s lifecycle. So, easily you can keep the first row of this board and use it in next sprints too. It will help the team to have balanced estimation during all over the sprints or releases.

Maybe you like: 5 Steps to avoid Imposter syndrome for Agile Coaches

About the Author:

Asad Safari is an Enterprise Lean/Agile Coach. He works as an Agile coach for more than 7 years with several enterprises and startups. He has more than 14 years experience in the IT industry as a Software Developer, Tester, and finally agile practitioner. You can follow Asad on Twitter and LinkedIn.

“I have no idea what I’m doing?”

Have you experienced this feeling? As an Agile coach or Scrum master, you think that you are not valuable to your client/organization, and you don’t have a good feeling about your accomplishment. We call it “Imposter syndrome.”

I saw some tweets in the agile community, and this idea came to my mind that most of us have a common sense and we should talk about it.

Based on Wikipedia:

Impostor syndrome (also known as impostor phenomenon, impostorism, fraud syndrome or the impostor experience) is a psychological pattern in which an individual doubts their accomplishments and has a persistent internalized fear of being exposed as a “fraud”. Individuals with impostorism incorrectly attribute their success to luck, or as a result of deceiving others into thinking they are more intelligent than they perceive themselves to be.

Yes, It happened, It has happened to all of us. I’ve experienced it many times in my career.

When it comes to your mind, it makes you sad. Something like that “I have no idea what I’m doing.”

In this story I don’t want to explain imposter syndrome, I want to share my personal experience and some tested practices to solve this problem.

Several years ago, I started my journey as an agile coach in a big company. They hired me to make them agile. They had more than five development teams. We began our journey with observation and assessment phase. After that, we did training and different workshops for teams. Everything looked good for several months; you do training, guys come to you and ask about questions and recommendations, you have a good feeling, you do tangible things that are appreciated for everybody…

After some time, teams are doing their business as usual. You need to follow them, and you ask them to do some practices, but most of the time they are busy with their affairs. I fell to thinking the question that am I helpful here anymore.

Why did it happen?

It’s about factfulness. We are helping the organization, but we don’t have enough facts to show ourselves. Organizations always have some new problems, and it triggers the feeling that the organization’s performance is worse than the past.

I recommend to read the book “Factfulness: Ten Reasons We’re Wrong About the World — and Why Things Are Better Than You Think” book by Hans Rosling. In this book, Rosling suggests the vast majority of human beings are wrong about the state of the world. We need to learn to separate fact from fiction when forming our opinions.

The world can be both bad and better. Progress comes bit by bit, But without facts, our minds are occupied by feelings.

So, as an agile coach we need to be factfulness about our work and organization, but how?

Practical Factfulness for Agile Coaches

1- Focus on one or two teams

Don’t try to make all over of the organization be agile in the first try. As an agile coach, you have capacity. For larger organizations, we may need to have more than one coach.

In my case, I have focused just on two teams at the same time. Some guys said it’s a kind of sub-optimizing, and don’t do that, but it’s about focus..

2- Find three main issues or problems

Before any act or recommendation of any solution, try to find their main concerns. Why are they looking for a new way? What are they looking for agility? What has stopped them from doing a great job?

In my case, one of teams has several significant problems, but their main problem was that “The team don’t finish and deliver their committed works at the end of the sprint,” and it made their managers worried and created a cultural mistrust and … .

3- Create a coaching card

I got this idea from agile42 and I have designed a coaching canvas. It can help you to frame the problem and try to be factful.

Don’t be worry, be factful 🙂

Download Coaching Canvas File.

You can find my real card bellow without any additional description.

Title: Team don’t finish their committed works at end of the sprint

Context:

At the end of the sprint, most items are not complete, and QA doesn’t have enough time to test everything, because most things are done in the last days of the sprint.

While a lot of work remains, some team members cannot do anything.

Hypotheses:

We think we can solve this problem with the following:

1- Decreasing team size to 5 people

2- Better user story breakdown -> Small user stories

3- Better planning meetings and Effective daily standups

4- Visualize release count per sprint on team’s board

Goal:

The goal is to make the team able to publish multiple releases during a sprint and complete the most committed issues at the end of the sprint.

Metrics:

1- More than two releases to production in each sprint

2- Completing ~70% of committed issues

3- Not changing the length of the sprint

Metrics are so important here because they will assist us with factfulness. The recommendation is to set the metrics immediately after we have agreed on a goal, not after defining the steps. We need to make metrics clear and actionable. To say that “progress has been updated regularly” is a good beginning, but in itself, it’s not enough.

You can create this cards yourself or create it by the team. But please put indicators where the team can see it every day.

4- Share and create an agreement on coaching card with your main stakeholder

It’s a secret sauce. Somebody in the organization has hired you. Maybe she is a CTO, CPO, and CEO or…. most of them are busy guys, and after a while, they will forget what you are doing there, and they will say, why are not we agile yet?

In my case, she was CPO. She was a busy person, and I’ve needed to follow her up for finding free time.

You need to create an agreement with them on your coaching cards. Share coaching cards with them, ask them to check cards and metrics. Will they be happy if the team achieves these results? Get their idea and create an agreement with them.

5- Review results with stakeholders and teams

In each period, maybe monthly or quarterly, review results with primary stakeholders and team members. You can do it in a retrospective meeting or any other meeting.

This will help you to see your work’s results and maybe get appreciation from your stakeholders. As an agile coach, we need this kind of acknowledgments.

Link on medium

By: Asad Safari 🙂