Do I misunderstand, or is this mismanaged Scrum?

• The team work through the Product Backlog for two hours to estimate anything (or as much as possible) that is not estimated just in case it is included in the next Sprint
  • Estimates are broadly comprised of:
    • Developers think 3 (because between 1-3 days work) and QA think 5 (because multiple test points) so we'll put 5 SP as the estimate
    • Developers think 8 (because 2 weeks worth of work) and QA think 2 (because new module, more cookie cutter testing) so we'll put 8SP as the estimate

This doesn't seem inherently wrong, at least on the surface. Scrum doesn't say anything about how to perform refinement, and some teams do prefer to do a group refinement at a scheduled time. However, it may not be the best use of everyone's time, especially if there's more ambiguity in the work that would need to be addressed. I would also be concerned with having too much of the Product Backlog estimated - the definition of work and/or the estimates could be made obsolete by changes to the Product Backlog or the product itself.

The thing that stands out most for me here is the separation of developers and QA rather than a team-centric approach to getting the work to a Done state. This is something that I'd want to better understand and address.

• Product Owner & various departments ask Scrum Master how many Story Points are available for the Sprint.
• Scrum Master calculates that Employee #1 has an average of 1.3SP per day and 8 working days in the Sprint, Employee #2 has an average of 0.8SP per day and 10 working days in the Sprint, etc... this determines the Story Point allocation for the Sprint.
  • Only the development allocation is factored into the number of available Story Points
• Product Owner & various departments load the next Sprint with a series of tasks (no common goal - completely separate components, some improvements, some changes, some fixes) that equal the Story Point allocation
  • Some tasks (8SP and above) are split into two, but not by deliverable. The completion of the first portion rolls into the next Sprint to be completed before merging to trunk.

The work that is described here should be done at Sprint Planning, not before Sprint Planning and definitely not be the Scrum Master and/or Product Owner in isolation from the Development Team.

The Scrum Master should not be answering questions about the team's capacity, and Story Points should not be equated to time by anyone. The Development Team should be basing their capacity on their past performance. If using Story Points, then the concept of Yesterday's Weather is commonly applied to look at the velocity of the most recent few Sprints to determine how much work is suitable for the upcoming Sprint, but this is done at Sprint Planning and not before. The whole idea of allocating Story Points to people and Story Points per unit of time is an abuse of Story Points.

Someone other than the Development Team "loading" the Sprint is indicative of a push approach, rather than a pull model.

The lack of a Sprint Goal shows that Scrum, as it's defined in the Scrum Guide, is not being fully applied.

• Scrum Master presents to the team the agreed upon Sprint Backlog and asks if it is achievable. If the team say no, they are told to get as much as possible done anyway but nothing is removed.
• The Scrum Team do not have the ability to request items to be added to the Sprint Backlog
• Individual tasks are allocated to individual members and the whole Scrum Team plan the minutiae of the task (change this controller, update this view, use this library in this way) - creating 'Burndown Items' per task
• Product Owner can request (demand) that tasks are done in a specific order in order that they can be released on completion - before the Sprint demo.

This is a pretty poor Sprint Planning and doesn't align with what Sprint Planning is in the Scrum Guide. It doesn't show a collaboration between the Product Owner or the Development Team and it seems to describe the Scrum Master as more of a project manager than a coach and facilitator for the Scrum Team. Again, the assignment of tasks to people shows a push mentality rather than a pull model and the focus on burndown seems to be more of a focus on output rather than outcome.

• Product Owner can put tasks into the Sprint Backlog at will with a caveat "If there is too much work now, let me know what items may need to be removed and we'll decide if we can remove them"
  • Invariably a task of the same Story Point estimation is a candidate for removal, as there isn't a defined Sprint Goal.
• Any identified risks - tasks that may not be completed - are placed on a "risk list" and monitored, but never removed

The Sprint Backlog is the sole responsibility of the Development Team. The Sprint Goal is created and Product Backlog Items for the Sprint Backlog are selected as a collaborative effort between the Product Owner and Development Team, but there are other aspects to the Sprint Backlog such as the plan for delivering (which may be seen as breaking down the work into smaller tasks or chunks, but there are other options as well) that are the responsibility of the Development Team.

• Any incomplete Sprint Backlog Items are moved to the next Sprint

The Scrum Guide describes incomplete work from the Sprint being placed back into the Product Backlog. However, if it truly is the next most important set of work, it would end up at the top of the Product Backlog and being worked on in the next Sprint is a likely outcome. To me, this doesn't seem like a problem since it's achieving the same result. However, the lack of team collaboration over the Sprint Backlog and Sprint Goals is a problem.

• There is a rota where every Sprint a different member of the Scrum Team is removed from the team and placed onto the 'Bug Rota' - working through any and all bugs with no clear goal other than to complete as many as possible.
  • This changes the Scrum Team make-up
• Once a member of the Scrum Team has completed their assigned tasks, they start work on the next Sprint's (already agreed upon by the Product Owner) Backlog and/or pick up some non-Sprint Bugs.

This goes against the value of focus. Changing the make-up of the Development Team does have impact on the ability of the team to effectively forecast (but it sounds like the team isn't doing much forecasting on their own right now) and get into consistent habits.

It's normal to have bugs come up in products, including urgent production issues from live projects. But these should be accounted for when determining estimates and capacity for work during Sprint Planning. Having a person assigned to fix bugs, in isolation from the rest of the team, can be demoralizing. It's also not conducive for sharing knowledge collaborating toward a high quality product.

The numerous articles and things I've read, and the 'Agile Scrum' course I've attended have said that a large portion of this is wrong. This feels more like Kanban dressed up in Sprints. Many members of the Scrum Team have raised their concerns only to have them batted back by the Scrum Master as "we've been on the CSM course, we know best".

I'm familiar with Kanban. This isn't anything like a good Kanban implementation, either. There's too much pushing, there's not enough collaboration, there's a lot of waste in the process.

If I'm not (completely) wrong, how can I effectively communicate that these practices are wrong? I've tried giving examples and parallels. We've had an 'Agile Coach' in who guffawed at the idea of allocating Story Points based on the individual averages for developers, who baulked at the suggestion that we let people know their average and monitor their performance based on their average Story Points delivered, etc...

It seems like you've tried, unsuccessfully, to communicate this. These things that the Scrum Master and Agile Coach are practicing aren't in alignment with the values and principles of Agile Software Development or Scrum. They seem pretty set in their ways. Unfortunately, some people are like that and I haven't found a good approach for dealing with that yet.

If I'm not (completely) wrong, how can I effectively communicate that these practices are wrong?

Might the Scrum Guide be of use here? Have you reviewed it as a team?

Thanks both for coming back to me. While perhaps no further forward, it is good to know I'm not way off mark. 

Might the Scrum Guide be of use here? Have you reviewed it as a team?

I have proposed / suggested / tried this before, and again yesterday - not in a combative way - the push-back was "we're 'doing Agile' and it is working for us so what's the point?". The old adage "If it ain't broke, don't fix it".

Story Points should not be equated to time by anyone

Since my first post, we are now reporting productivity to the Senior Management Team based on the number of Story Points achieved per month (every second Sprint) and the number of tasks completed. The Scrum Master and Product Owner have suggested that we track an 'average' time to complete each Story Point value so we can see deviation from this average to know that the Story Point values aren't being artificially inflated to gain 'productivity points'.

Not only breeding a mistrust between the Scrum Team and management, but also mapping Story Points directly to time. 

I'm familiar with Kanban. This isn't anything like a good Kanban implementation, either. There's too much pushing, there's not enough collaboration, there's a lot of waste in the process.

I didn't mean to imply that it is Kanban.

Dear Hester,

Your initial gut feeling and analysis was correct. This is not the Scrum and neither the amalgamation of good practices from Scrum and Kanban. This appears to me as SQUAT (Status Quo Using Agile Terminology). There are several reasons for my inference.

1. The lack of defined Sprint Goal
2. What appears to be a permanent separation of Dev and QA
3. Reporting is based on the story points not the achievement of any goals
4. No reestimation or recalibration of commitments during the sprint.
5. Improper use of risk management metric is the scrum team (though there is no specific guidance on risk management in the Scrum Guide), which may result in complacency from both Dev Team, PO,SM and even stakeholders over the period. As a general principle, risk management metrics are intentionally structured to maintain the fluidity.