Agile Planning

It’s Time to Deprecate Story Points

It has been known for quite some time in the agile community that estimation is waste.  And yet, I still see many, many teams spend huge amounts of time in story pointing sessions.  I’ve experienced people passionately debate whether a user story is 3 points or 5 points.  If that isn’t a waste of time, I don’t know what is.

I’ve stumbled across a pattern over the last 5 years or so that has probably always been there, but, hey, sometimes I’m a little slow (and, I’m not the only who’s noticed this by the way).  When I first noticed it, I was a little surprised.  Once I noticed it, I saw it everywhere.  But it made complete sense.

When estimating with story points, the purpose is to determine a velocity (total number of story points completed in a sprint) so that you could estimate how much a team can deliver within some period of time.  I was a big believer in this…it really worked.  It helped us be able to say “no” to more work during a sprint.  Drawing that line in the sand was awesome as we had real data to know where to draw that line.

While teams discover their velocity in points, I thought I would see how velocity correlated to number of user stories completed.  And then I found the pattern.  Teams consistently not only delivered approximately the same number of story points during a sprint, they also delivered approximately the same quantity of stories.  When I first discovered this, the team I was working with consistently delivered between 9-11 user stories every sprint.  I went back at least 5 sprints, and it was always the same.  I thought maybe that was a fluke.  So, I looked at other team’s (on the same initiative) product backlogs.  The same thing.  Consistent number of stories every sprint.  

Afterwards, when I worked with other teams, I noticed the same thing.  It’s extremely consistent.  And it made complete sense.  When you decompose user stories to the point where they fit into a sprint, you will find that some stories you thought were tiny are a little bigger, and vice versa.  Ultimately, it “comes out in the wash”. 

I do have one caveat.  If, for some reason, your team(s) have a tough time decomposing stories and the size of them vary wildly, then this may not work so well.  However, instead of trying to estimate better, you should put your efforts into learning how to decompose your work into smaller batches.  There will be a much bigger payoff.

Having experienced the widespread and consistent pattern, maybe it’s time to deprecate story points.  I know what you’re thinking, “what about long-term planning?”.  Long term planning smells like waterfall.  However, it is completely reasonable when a customer asks, “when do you think this will be done?” or “how much can you complete by October?”.  Ultimately the answer is always “we’re not sure”, but that doesn’t always fly.  There are other ways to provide a target (or a guesstimate).  But, alas, I’ll leave that for another post!

What do you think?  Is it time to deprecate story points?

, ,

Plan Your Agile Training

When it comes to Agile training, there are a limitless number of options.  It can be a bit overwhelming to decide who should be trained, what type of training they will need, and when to begin.

I’m going to list a few training options here in this blog post, but I want to start by saying that One80 Services exists because we recognized the need for customized training and individualized coaching.  We begin every contract with a conversation, to ensure your training will meet the needs of your team or organization.


Reducing Silos

The first step in reducing silos is to ensure training occurs on a cross-functional team.  Simply sending a few “key members” of a team for training without realizing that every member of an Agile team is a “key member” can slow or even block your transition to Agile. 


Basic Agile Training

Basic Agile training creates a foundation on which to build, and goes a long way in answering the “why” behind the roles, artifacts, and events which are included in many Agile methodologies.

Advanced Agile Training

Advanced Agile training is for those who have already begun their Agile journey and are ready to figure out some of the more complex solutions and methods. 

Targeted Deep Dives

Targeted deep dives are for teams who want to improve in one area.  For example, teams who want to improve their user story writing techniques, story sizing, metrics, or improve their meeting facilitation skills.

Agile Leadership Training

Agile Leadership training helps anyone in a leadership role – from CEO to ScrumMaster – understand how leadership changes when an organization becomes Agile.

This is not a “choose one” scenario.  

Depending on your needs, we may combine one day of basic Agile training with one day of advanced Agile training, followed by one day of deep dives into relevant topics or skills.

Maybe what you need is targeted leadership training, so we’d spend a half day on basic Agile training, then move on to Agile leadership training including facilitation, team structure, and metrics.

You may have no idea where to start – that’s okay. Learning about teams and determining training needs is our speciality.

It all starts with a conversation. 


Agile training can occur at the start of a project, in the middle, or even toward the end.

“Lost time” in training is a common and valid concern.  We like to remind people that the time you spend in training is quickly made up by the improvements made to your process.  

It’s also relevant to point out that in our workshops, a portion of our training is often spent working on your actual project.  For example: A three day workshop may involve 1.5 days of courseware and 1.5 days of writing your user stories and grooming your backlog.

We don’t like waste – we make the most out of the time we spend with you to ensure we’re not wasting your time or ours.


Typically, we come to you and teach on-site at your location. If your site doesn’t have space available for training, we will provide a location for our course.


There is a method to our madness.

We do provide pre-packaged courses for companies who know exactly what they need.

But in our 20+ years of experience, a customized approach works best for most teams.

We have seen pre-packaged courses leave teams with questions and a lack of solutions. Blending our courses together to create customized learning for each client results in teams leaving us with solutions to implement immediately, as opposed to leaving teams with a few days of book learning.


Much of the “how” depends on your organization, team, and project needs.  

Ideally, our courses are designed for 10-20 people.

  • The minimum size would simply be due to our belief in teaching cross functional teams. Ensuring that everyone is on the same page from the beginning. Depending on team size, potentially training more than one team per course.
  • The maximum size would be due to our desire to enable personal contact and interaction with each person in our course. Group interaction improves with smaller class sizes.

That said, we’ve taught in rooms of 100+ and we’ve worked directly with individual learners.  It really is all about your individual needs.

The best first step is to give us a call.

Do you want to know more about Agile implementation strategies?  Check out our free guide here.


Release Planning – Reducing Silos, Creating Understanding

Release Planning is becoming a controversial topic in the Agile community. Purest are saying that if you are doing true Scrum you should release working software often – as soon as an MVP is ready.  The Team should be releasing frequently in order to learn from their customers and users.  I agree 100% with this paradigm; however, on large scale projects with many teams, stakeholders, dependencies, and risks this can be difficult.


We work with many clients who are developing larger software projects. In organization with multiple teams and product owners, priorities can be to coordinate.  These clients are not large enough to implement a full Scaled Agile framework, so release planning sessions gain importance.

I recently facilitated a Release Planning session for an organization which took an interesting turn.  The meeting became less about writing Epics and Stories, reviewing velocity, and charting a path towards release success.  Don’t get me wrong, we definitely accomplished these tasks.  The more important lesson from the activity, however, was getting everyone on the same page.

I started the session by asking everyone in the room to quickly define the scope of the next release on a post-it note.  It was clear from other conversations I had with the people in the room that they had already completed dozens of meeting to define the release.  I figured this was a no brainer.

I received about 6 different visions.  Not just slightly different but COMPLETELY different.  How could this be, how could the dozens of meetings not have generated a scope plan?  Simple: Personal Agendas.  Everyone in the room had a different agenda and view point (reduce customer complaints, simplify architecture, upgrade platform, introduce cool features, etc.).  Planning had taken place in silos.  Each department had meetings to discuss scope, but no one had ever brought the silos together.

We took a quick detour and spent an hour defining scope by listening to each person’s ideas, priorities, and customers needs and wants. At the end of the first hour we had a well-defined understanding, which helped simplify the release planning and give the Product Owner and Team a cross-functional release target.

On large scale projects with many teams, stakeholders, dependencies, and risks – sometimes reducing silos and creating understanding before building a release plan is the simply the smartest way to go.

Talk to Us Today

The Agile Snowplow Trap

I am one of those Scrum Masters who likes to talk in the abstract and with analogy. I find that it helps my teams to understand the concepts that I am attempting to coach. If I start throwing around a lot of Project Management terms, you know, ‘Risk’ ‘Contingency Planning’, ’Failure’, ‘Release Planning’, the team starts to shut down. I suspect they think, ‘There he goes again on another one of his PM things’, eyes glaze over, cell phones come out, people start daydreaming about their last golf outing. I have learned to avoid these types of coaching opportunities and instead try and put the concepts in terms that everyone can relate to.

Several months ago, I noticed that my High Performing team had started the bad habit. They were taking the stories that the Product Owner had provided, building the release plan and executing. With full knowledge that the Stories had not been broken down into sizable chunks that could be executed in a given sprint. Also, without helping the Product Owner to understand any additional Stories which may have been missed (I call these ‘Hidden Stories’).

The odd thing that continued to happen was that the team would even point the stories during Release Planning, as if they could be completed. From a Scrum Master and Product Owner perspective we thought we always had a fully formed Release Plan and Product Backlog, when in fact we had glaring holes.

In order to help the team understand the dysfunction that we had become trapped in, I developed the analogy of snowplowing (it came to me one day in the middle of one of our blistering Nebraska winter storms). I am not sure how snowplowing works in most neighborhoods, but in my neighborhood the snowplows blow the snow to the side of street (usually covering all the cars). However during times of extra heavy snow the snowplows actually start to push the snow forward and the trucks needs to work even harder to get the snow removed.

This was very similar to what was happening on our Product Backlog. When we would first start a release, the team would slide stories to ‘Done’ easily. However, when the ‘Hidden Stories’ started to surface, the existing stories got pushed into future Iterations to allow room for the ‘Hidden Stories’. Thus begins the effect of Snowplowing, or continuously pushing stories into future Iterations to make room for the hidden work.

During a Retrospective, I brought this observation up to the team. After much debate, the team determined the best approach to stop the Snowplowing. We took the time to redo Release Planning, write the ‘Hidden Stories’, repoint correctly. It was a great exercise and learning experience for the team.

Since that day, I have noticed that when these situations come up, and sometimes they can come up unknowingly during Sprint Planning, I hear the team say ‘That is Snowplowing’, and they retrace their steps to make sure they are not falling into the old traps.

Talk to Us Today
post =