Story points are a common practice in agile planning and in this article I wanted to talk about some of the theory and my personal experience with pointing. I’m going to assume that all readers are aware of what story points are. But, if you’re not, take a quick peek at the wikipedia article.

I wish I could write more about the history of story points but I’m strugging to find information on that. I heard a rumor that a famous consultant was sick of being asked for deadlines so they came up with idea of points instead. Because the points don’t directly relate to units of time, it drove the concept home that these estimates are just estimates.

Whether or not this is historically accurate, it still explains why you should avoid estimating with units of time. Here’s a case study where a team tried to estimate in hours instead of points:

With hours, we measure our progress and declare something like “we’re doing 22 hours per week”. This can annoy (why aren’t we going faster?), confuse (wait, is this in actual hours or ideal hours?) or even anger (this is a team of slackers!). But a statement like “we’re doing 22 points per week” doesn’t generate these same emotions. It may elicit initial confusion (what’s a point?), but that’s just an opportunity to explain what’s really going on.

Even though points don’t directly relate to time, they can still be used for projections by a Product Manager. If you know the average number of points the team completes per iteration you can leverage this to project when milestones will be reached.

But points aren’t just a compromise to giving specific deadlines. The act of pointing stories is a useful process to the development team. For example, if I think a story is really simple and easy and I say it’s a 1 but my peer says it’s a 5, that means there’s some disconnect that needs to be ironed out. Without story pointing, this disconnect is never discovered. This creates situations where a developer says, “I’ll have it by lunch” but it takes 2 weeks. Or, “This is so hard I think we should consider if the effort is worth it” and the story ends up taking a day.

Paradoxically, story pointing can be used to keep meetings short. If you calculate the average points you complete per iteration and in a pointing meeting you’ve already pointed 2x that average, you know you can end the meeting early: It’s highly unlikely that you’ll be able to get through the work you’ve already pointed so there’s no point in staying in the meeting.

Slight tangent: Sometimes Product Managers like to point as many stories as possible because they think it gives them better projections. In practice I see the opposite being true because once you get two weeks out the points stop being based on reality. Stories start to depend on other stories being completed first. The prerequisite stories can effect the level of effort on future stories in ways you can’t predict. In my opinion, I don’t see a lot of value in pointing more than 2 weeks in the future.

Lets assume that after that 1 vs 5 point discussion, we agree that the story is a 5 pointer and that 5 points is very high. How can that be interpreted and leveraged? Well when a story is pointed very high that usually means there’s a lot of uncertainty in it. Sometimes that means the requirements aren’t clear and the story needs to be rewritten. Sometimes that means the team has no idea how to implement the story and it will be a research task.

Be wary of working on high point stories. They often take much longer than anyone could have anticipated. It should send the message that even though this will be started this iteration, it may not be finished this iteration.

I wanted to end this article by mentioning that there is a “No Estimates” Movement. My interpretation of this is every story is 1 point. I have to admit the concept is appealing when I put my developer hat on. But when I put my Product Manager hat on, the idea doesn’t seem very appealing. I’ve yet to experiment with “No Estimates” so I don’t know how it would play out in practice.

I hope this article helped you think of story points in a way you hadn’t thought of before. If you have a different perspective, please let me know via a comment to this article.

As we discussed last week, A Good PM is a Communication Gateway. This is a diagram of how communication flows to and from a good PM (Product Manager):

If you want to know more details about how a good PM interacts people around them, check out my previous blog post.

This time I want to talk about how bad PMs interact with people around them. The communication flows look more like a food chain. If you’ve never seen a food chain before, it looks like this:

Similarly, a bad PM communicates like this:

I call this a food chain communication style because communication flows in one direction and the arrows at the top often point to multiple layers below.

The PM usually transfers the messages from the stakeholders/customers directly to the developers with no translation or pushback along the way.

This lack of translation means that the developers have to spend time converting stories into use cases themselves. As I said in the previous article, translating requirements into use cases is easily a part time job. This takes away from the time that the developers are building software and instead makes everyone into a mini-PM. These raw requirements may not make much sense or be unclear. The developers will waste even more cycles trying to get clarification.

Getting this clarification is not always easy. A bad PM tends to not understand “why” they’re asking the development team to implement something. This means the developer has to ask the PM who to ask (wasting more cycles). In a worst case scenario, the PM will actively interfere with the developer communicating with a stakeholder to get clarification. As a result, the wrong thing is often created, has to be undone, and created again the right way. This is very demoralizing and a waste of time for the company.

When a PM doesn’t know “why”, it is very difficult to prioritize requirements. Without knowing “why”, the loudest stakeholder/customer goes first. And if there are multiple squeaky wheels, then all requirements get to go first. Everything becomes top priority. In other words, the developers’ bandwidth, workload and velocity is rarely considered and new requirements are added to the beginning of the pile of work that’s already in progress. These usually come in the form of interruptions to the developers who are unable to wrap up the stories they’re working on because there’s always something new that’s more important.

Usually when a PM doesn’t know “why”, they don’t push back on stakeholder deadlines. When a stakeholder learns that the PM prioritizes the loudest person first and doesn’t push back on deadlines, the stakeholders often take advantage of this by creating a bunch of artificial deadlines so that their features get worked on sooner. The PM will pass these deadlines off to the development team who will suffer as a result.

In these environments, it can be common for stakeholders to reach out to developers directly. As I said in my previous article, this can be advantageous sometimes but it causes a lot of issues if it’s habitual. When the PM is bypassed, they get out of sync with the stakeholder and the product vision. The PM will know less and less about what’s going on in the project and why. The dev who talked to the stakeholder may be working on something that the PM has no idea about. This is another way prioritization issues occur because the developer is being told different things should be worked on by different people.

Finally, a bad PM tends to involve and include the developers in lots of meetings. They do this because they’re not putting any forethought into what needs to be worked on next so they place the burden on the development team. These meetings interrupt a developer’s train of thought and take away time that could be better spent developing. Some meetings are necessary, but most can and should be avoided. Better to have face to face contact whenever possible.

If you’re at a company and have experienced these symptoms, the PM needs to provide more value to the team. They need to understand the project, understand “why” all requirements are requested and act as a communication gateway between stakeholders/customers.

I was reading this great article titled, “The Quiet Crisis unfolding in Software Development”. I found it to be a great read. You should really check it out. But, there was a part of the article that I found interesting:

Your employees like working for you—right?—which means turnover should be low. Don’t optimize for developers leaving which should be the uncommon scenario. For best results optimize for the common scenario.

Optimizing for the common scenario means giving developers primary ownership of portions of the code base and not allowing other developers to change that code without approval from the primary owner. This results in higher productivity since any given developer is more likely to be familiar with the code in which they will typically be working.

As someone who pair programs all day, I completely disagree with this and think it’s dangerous. I can talk about the bus factor, but I also think that staying on one project makes developers unhappy.

The main reason I’ve left companies is because I got sick and tired of knowing what I’ll be working on if I work there for the next 5 years: The same thing I’m working on today. The truth is, it raises morale to work on something new once in a while.

Think about it: When you’re on an interview and you’re asked, “Where do you see yourself in 5 years?”, are you supposed to answer, “Pretty much where I am right now”? No, that would be a terrible answer and the interviewee wouldn’t want to hear it. They want to hear some ambition, about how you’re going to grow with the company, and how you’d be a good investment.

When you have a culture of always keeping people on the same project, you’re sending the message that they’ll always be trapped doing the same thing day in and day out unless they find another job. Nobody wants to keep working on that decade old code base, even if they created it. That’s about 5 generations of web frameworks and techniques. If you keep working on the old code base, your skills are going to become stale and irrelevant.

not allowing other developers to change that code without approval from the primary owner

I also think this is a dangerous policy. First of all, it creates artificial bottlenecks in the system. If I need this bug fix in some code I depend on but the guy who approves the change is on vacation, my progress just became blocked.

Second, this psychologically encourages peoples egos to be tied to their code. “You can’t touch that because that’s mine” / “You can’t critique that because I made it” / “You can’t improve that because it’s mine“. This is unhealthy and uncollaborative. I know it’s annoying when a novice comes into your code base and commits something that doesn’t follow your coding style or even introduces a bug. But, the reaction to this shouldn’t be to quarantine off all code. The reaction should be to teach this person and work with them to improve the (not your) code base in the future.

Third, it makes developers care more about their piece of the puzzle than the big picture. If there’s a problem somewhere else, they’ll only be interested in it if it directly effects their code.

Fourth, siloing code tends to go hand in hand with siloing knowledge and skills. Some code bases are going to be high quality, others are going to be poor quality. And if the owners of each don’t interact with each other, that’s the way it’s going to stay. In a true vacuum, this might be ok, but eventually some of the good code will depend on the bad. This will cripple your company’s ecosystem of software.

A better approach is a policy that everyone is responsible for all code bases. There should be no barriers to making an improvement to any code in the ecosystem. Yes, developers will have varying skills and mistakes will be made. But if you also have a policy that it’s ok to make mistakes as long as you learn from them, the lower skilled developers will improve their skills faster than being left to their own devices.