I should note that I am by no means an expert in agile methodologies. I also fully subscribe to the idea that the vast majority of people I meet and work with aren't either. I have even met professional agile methodology coaches who have some wild ideas.

The one small topic I wanted to focus on today is related to production support with an agile software development team. I've seen this come up many times. I don't know what the ratio is, but I suspect that most software products don't have a dedicated support team. This means that once a software product has been released to production and users are using it, the development team needs to balance support with enhancements.

I have witnessed sprint planning meetings and stand-up meetings where production support work has come up and people have fallen into the trap of trying to decide how many points of support should be allocated per sprint.

There are a few problems with this thought process in my opinion. First, all work does NOT need to be pointed. Pointing is an exercise where the team tries to apply a relative size to the planned development items of enhancement work or defect fixes. The key is that the team knows something about the work. Ideally, the solution is known and the scope is fixed. But, even if the solution isn't known or the scope is not fixed, it is arguably possible to point such a story or at least create a spike for that work. (I subscribe to the idea that spikes should NOT be pointed.)

Second, activities related to incident or user support that haven't even happened yet cannot be pointed by definition. The work is undefined. The team often knows how many hours they spent doing support last sprint, so there is a temptation to try and assign points to that time. I would suggest not even trying.

Finally, points are only to assist with planning as a trailing indicator, nothing more. The previous velocity can be invalidated easily. Scheduled vacations, company events, paternity/maternity leave, etc. can make the team's velocity value almost useless compared to the team's current and unusual capacity. But, that's ok. Story points aren't special. They're just a planning tool. Don't give them more power than they deserve.

These days, many loud voices are ringing the bell that "Agile" is dead or broken. I don't think you should throw out the idea of following an agile methodology. I believe you should take the best of what works for your team, your product, and your users, make adjustments to suit your purposes, and stay focused on the real indicator of success: delivering value to your users and the organization.