Another way to mess up Scrum, since I’ve already gone into adding work during a sprint, scheduling future sprints, and failing to prioritize, is…

Fake Reporting

Fake reporting is endemic in dysfunctional Scrum shops. Here are some examples:

• “My meeting ran late so I burned an hour off the memory pooling story.”
• “The boss didn’t want to sign off on DevOps integration. I just rolled it into the story about dropdowns on the UI because it has too many hours anyway and called it “refactoring.”
• Using “defect bucket” as a recurring Sprint Backlog story. Seriously!
• You can’t submit your time sheet to get paid without assigning all your time to an assigned task.

The payoff from fake reporting

In the short term, fake reporting is your friend. You don’t have to justify that meeting time. You get your paycheck like you’re supposed to. You have a way to manage unexpected work that comes back to bite you from past sprints. And so on.

The problem is that Agile absolutely relies on continual, accurate feedback. Management and the Product Owner cannot make realistic decisions if you keep feeding them inaccurate information. Going down the list of examples above, let’s look at the effects.

• The boss doesn’t realize someone in the corporate food chain is taking advantage of the team by breaking your time box. Either you should have been let out of the meeting on time, or it should have been better scheduled. Additionally, burning an hour off another story? Now all your future estimates are skewed and the team lead has no idea how close you really are to having that story actually done. Lies! All lies!
• Feedback goes both ways. The boss doesn’t want DevOps integration, the boss doesn’t get DevOps integration. Let the boss make that priority call. She’s probably wrong, but the only way she’ll find out she’s wrong and adjust her future decision-making is if you allow that to happen. If it’s not on the sprint backlog, it doesn’t get done in this sprint. Period.
• There is no such thing as a “bucket” in Scrum. The “bucket” concept, which I saw in extensive use at a local bank, made it impossible to know what was in and out of any given sprint. First off, if a story’s implemented with defects, it’s not done so it should still be on the Product Backlog. But if the defect is undetected until later, fine, you make another story for it (if the defect affects only a small part of the story, or if it’s in legacy code that doesn’t come from stories) or pull the story out of the Archive and consider it a do-over. I’m sorry, no, if you can’t account for specific defects in the Sprint Planning Meeting, then your sprints are too long. Finally, if you can’t possibly account for all the urgent defects that will “inevitably” pop up during a sprint, take them out of the Scrum framework. Simple. If you’re doing new work that popped up during the sprint, fine, but that’s not Scrum.
• This one creates probably the most lying of all, especially in cases like mine when you’re always the “new contractor” who doesn’t immediately have very much work assigned. You’re at work for forty hours! (Usually more, but still.) You have to account for forty hours! You don’t even have the option of going home early and accepting unpaid time off! So you literally aren’t allowed to not put forty hours into the time tracking system… but there’s often no task for “onboarding” or “orientation.” There’s just about never a task for “unproductive time.” About the only way that is even allowed is for you to assign those forty hours to things you’re not even working on at all. So the boss gets wildly inaccurate time reports that are therefore essentially useless for planning and feedback.

Things that Scrum leaders need to do

Did somebody lie and tell you this job was easy? No. It is your job to enforce timeboxes on meetings. It is your job to allocate a realistic amount of time off the burndown charts and off the Scrum framework for duties that aren’t part of the Sprint Backlog.