More Agile Great Debates – Part 7

In this seventh episode of my blog series on Agile’s Great Debates, I cover five more topics of contention among Agile practitioners:

1. Use of Story Points is Required
2. Job Titles are Still Important When Using Agile
3. It’s okay to compare the Velocity of different teams
4. There can still be a Project Manager on a Scrum Team
5. There’s no need for Business Analysis skills when using Agile

Use of Story Points is Required

I don’t know how the use of Story Points became so controversial – maybe it’s because people are confused about what they are for. So, let me clarify: Story Points are just a tool to help the team forecast what they can realistically accomplish in future Sprints. A team’s velocity is NOT a measure of performance (although it’s often misused in this way).

There’s absolutely nothing in The Scrum Guide about User Stories or Story Points. These terms and techniques are borrowed from other agile flavors that have evolved over the years. Scrum Teams may (or may not) use them, if they desire, but they’re certainly not required. The most mature teams don’t need to estimate at all – they go by instinct or simple story count.

I do like to use Story Points, but it’s just one way to size and estimate – there are also Ideal Days, T-shirt Sizes, Story Count, etc. Whatever one team uses is the one that works best for them – no one should dictate or prescribe how they do their work.

Job Titles are Still Important When Using Agile

People are very attached to their job titles – they often tie directly to a person’s pride and sense of identity. While I can appreciate this, it’s not that important when you’re on a Scrum Team. Job titles (and egos) need to go out the window when you become a part of such a team – your job title is irrelevant.

What matters is the skills you and the rest of your team possess. Each Scrum Team should have all the necessary cross-functional skills to develop a done increment at the end of each Sprint. I don’t care if your job title is Senior Developer, Architect, Business Analyst, or CEO – if you’re on a Scrum Team you fit into one of only three accountabilities: Product Owner, Scrum Master, or Developers (Team Members).

So, if you’re very concerned about your position being degraded by joining a Scrum Team, you might want to re-think your choice. Agile teams are all about collaboration, and working together to get the ball across the goal line. People who are only concerned with their reputation, personal career growth, climbing the corporate ladder, etc. should seriously consider not joining a Scrum Team – you’ll just bring the whole team down.

It’s okay to compare the Velocity of different teams

Each team is unique, and their velocity is a measure that applies just to that team. No two Scrum Teams ever operate in exactly the same way, especially when it comes to sizing and estimating their Product Backlog Items.

Some organizations make the erroneous assumption that velocity somehow measures how well a team is performing. This is totally wrong. Velocity is merely a forecasting tool to help teams when they’re planning – it gives them a guideline to choose only the amount of work they think they can realistically accomplish within a Sprint.

You can’t compare apples to oranges, and trying to do that to Scrum Teams is basically the same thing. They’re both fruits, sure, but that doesn’t mean they’re the same or that you’d use them in the same kinds of recipes. Can you imagine what an orange pie would look or taste like? Icky!

There can still be a Project Manager on a Scrum Team

Um… NO. There is no Project Manager role in Scrum (see my previous blog on this topic). Does that mean that Project Management activities don’t take place? The answer to this is also NO. However, on a Scrum Team, the work that traditional Project Managers do is distributed amongst the team. The entire team is responsible for delivery, not just one person at the top.

Scrum Teams are meant to be self-managing and self-directed, which means they don’t need a Project Manager to tell them what to do, when to do it, or how. The team works together to figure out the most valuable things to build each Sprint and comes up with a plan on how to accomplish those items within the Sprint timebox.

All of this said, there could still be a need for Project Managers within an agile organization – particularly if there are multiple Scrum Teams and they need to coordinate together. Another place that traditional PM skills might be used is at the portfolio level – just not at the level of execution.

There’s no need for Business Analysis skills when using Agile

Although there’s no role on a Scrum Team with the label of “Business Analyst,” very similar to Project Management tasks, the work of analysis must still happen. Whether it’s the Product Owner or someone else on the team, business analysis gets done somehow.

I know of one company that made the mistake of assuming that because there’s no title of Business Analyst on a Scrum Team, those skills were no longer needed. And they fired almost their entire analyst staff when they went “Agile.” That was a HUGE mistake. If anything, business analysis is even more important when developing products.

I would argue that having a team member with business analysis skills is crucial to the success of any Scrum Team. While anyone on the team could arguably do the work, someone trained and skilled in this profession would be best suited to doing the work. People with this skill set are also very good feeder candidates to become future Product Owners.

That’s a Wrap

 Another five Agile Great Debates are in the bag! If you have any comments, questions, or experiences you would like to share, please do so in the comments below.

In the meantime, check out the previous posts in this series:

• Part 1 – Devs as Sub-team, the 3 questions, product goal, refinement, hybrids
• Part 2 – SAFe, showing undone work, Status Updates, Agile = Scrum?, Review vs. Retro
• Part 3 – Product development, backlogs, Scrum: methodology?, PO owns budget
• Part 4 – Scrum Master needed?, silver bullet, adoption is easy, PO at scrum, 10+ teams size
• Part 5 – Conflict, leadership, technical POs, who should write User Stories?, extending Sprints
• Part 6 – Timeboxes, SM on 2+ teams, Managers at Retros, staying together, uses for Scrum

And, bonus, the one that started it all: 20 Great Agile Debates.