I love Pointing Things

I am not a blind advocate for all sides of agile development being perfect. I do prefer this method of development over waterfall, and even some SAFE methodologies, but it does have its flaws. What I love most about agile development processes is with it came the introduction of pointing things.

Point things is what I believe is at the heart and is the strength of Agile development. I love putting points to tasks and stories because from that ask comes team discussions. They will or at least should discuss the ask of the item as well as the approach to how that item should be completed. With that discussion comes what I love most, the shared of ideas and the sharing of previous learnings across the team.

Not every ticket should take the same level of discussion. There is a limit we should all be able to place on ourselves where talking gets in the way of doing. That though is why you focus on hiring smart but collaborative talent. It’s one thing to have the smartest in the room, but another to get that combined intelligence to be force multipliers to each other. Pointing can help encourage those who aren’t there yet.

Mr. Gorbachev, tear down this wallBreak Down Those Tickets!

The first part of putting points to any story is to make sure that it is small enough that it can be easily discussed. You must break it down. If there is too much room for subjective ways to approach the problem then you will lose the accuracy that you get from pointing. Humans aren’t great at estimations. A commonly referenced study by University of Oslo professor and Chief Scientist at the Simula Research Laboratory Magne Jørgensen found most estimates to be within 20 to 30% of actuals. However, it goes on to say that accuracy goes up with practice and refining focus. Practice happens simply from making it a practice to point things out, but the discussions on approach are what help a team to refine their focus.

In a hypothetical example, think of a project you worked on that you would think would take you a week, building a login portal. Now, take that project and break it down into those individual steps, building the view, building the connection to a user database, building a verification path for accurate info, building error messaging, and building an update path if credentials are wrong. Are each of those 5 things only a day of effort? What if 1 gives you an issue and now has thrown off the rest of the work?

By breaking down the project into the 5 smaller components in this example you get two things. You can refine the focus on those estimations, as well as give a more clear picture to the team on the status of your work. That is what the real effort that the team is working on.

Another consideration that you should take is at a single story, you have far more likelihood of an individual contributor taking the project on their own. By breaking this down as well, you have found potential areas where more people on the team can help support that single project. You reduce the high potential of burnout by reducing the potential of letting an individual work in isolation.

Why is pointing important?

I have heard it asked several times, that a team is on board for breaking work down and having collaborative discussions, but the pointing didn’t feel like it supported their efforts. They said the pointing just added one more process overhead and didn’t get the work done. No one likes process for process' sake.

Everyone should agree with the argument, if not for one small flaw. Adding the points calls out issues like a sign spinner directing you where to can buy a discounted sandwich. If one person says a ticket is 1 point and another a 3, you have a 200% difference. In no way are they thinking about the approach the same. It could also mean that one individual is more versed in an approach than another and you have an opportunity for cross-training. As a manager, if you think there is a way to get a 200% efficiency gain on future efforts from one of your team, by all means, invest in that. You find out, that someone knows what others don’t.

For the leader, the points give the measurement of the effort that the team is giving. By watching these metrics a leader can look for change and issues. By breaking down this effort into the types of work the team is focusing on, you can get further insight into what the team needs to focus on next.

A leader should never be an oracle. A leader doesn’t just know where to go. They know where to direct, because they look at what the team is doing, and know how to encourage the shift of focus for continual successful outcomes.

My Controversy

With pointing, the most controversial agile statement I will make that I have heard much disagreement about is that you don’t point bugs. I disagree. You put points to bugs for the same reasons you point to anything else. It’s an effort the team is putting forth, and the team should agree on the approach to fix the issue.

More importantly, putting points to bugs, let’s a leader plan. Every team will get a certain amount of bugs. No team has none. No human is perfect.

Bugs, like any type of work, show trends. When there is an influx, that means that technical debt, likely from rushed work needs to be addressed. A leader who understands how to look out for that knows that in that influx, they need to pivot their team's focus. As stated, the leader isn’t an oracle making up direction, but some can seem that way when they read the trends of the team’s work.

Where’s Victory?

Victory is when every ticket that your team works on is a 1. Don’t put this as a goal on your OKR, people will game that, and you’ll get problems, but it will show signs of an efficient team. It shows that they can take a project, break it down to its smallest amount, and be continually iterations.

Small elements are quickly understood, quickly built, and quickly testable which means the fastest and most efficient way to get value to the customer. Small elements of work give the least amount of strain when it comes to getting hit with context switching, the bain of every Engineery you ever met.

This does not mean that there can’t be larger points and shouldn’t be. For the right reasons a team, and that reason should always come from agreement, the team can have all sorts of variousions on their points. However, most of the time, the smallest, the most broken down work is the most accurate, and most efficient way, which is why I like that, and encourages others to see the success in it as well.