Dissecting a Status Pull
No, what is happening in your meetings is not a Scrum stand-up meeting, it's a status pull. In fact, it's probably worth dissecting this particular status pull to see why your "Scrum" process is failing.
The first two elements that your project manager (not Scrum Master, evidently) is asking are:
- The Original Time Estimate for the currently discussed task
- The Actual Time Estimate for the currently discussed task
The only practical utility for this information is to determine whether estimates were on-target or not, or whether there are hidden process impediments that were not planned for in the original estimate. However, gathering this information in this particular way is not very agile because:
- This information should already be transparent through the use of a Kanban board or other framework process. Having to ask for it explicitly is a "project smell" that indicates a fundamentally broken project process or an undocumented objective.
- Estimates are estimates, not commitments. As long as all stories that the team has voluntarily committed to perform during the Sprint are completed by the end of the Sprint, the individual story estimates (as opposed to the aggregate estimate) are not intrinsically useful except as part of a retrospective.
- If your process is based on 100% utilization, rather than a throughput-based pull queue, then it's neither Scrum nor agile. All agile frameworks require slack in the process; asking for daily deltas at such a granular level certainly implies an intolerance for the slack required by agile frameworks.
Now, the last item is particularly telling. Your PM wants:
- An explanation of why we were over or under
Getting better at estimating is a useful goal for any agile framework. However, one goal of Scrum is to ensure that the team does not over-commit; if there is extra capacity within the Sprint once all stories are completed, then the team can and should pull additional stories into the Sprint from the Product Backlog.
The question, as described, sounds a lot like stories are being assigned to the team for each Sprint, which is an epic fail from a Scrum stand-point. Even if that's not actually the case, it's another "project smell" that indicates that individuals are being "held accountable" (presumably by the PM) for the accuracy of individual story estimates, rather than for the team's overall progress in meeting the Sprint Goal for that iteration.
Mis-estimating is an issue that should always be communicated clearly during Sprint Reviews, and used as a learning process during the Sprint Retrospective. However, the tone of the question above implies that accountability for estimates is more important than anything else, and diverts focus from feature delivery to C.Y.A. delivery.
Using the Stand-Up to Coordinate Status
The following is incorrect:
[The stand-up] is a meeting to go over developer needs & issues in a manner that is relaxed and for the developers (no one else).
The daily stand-up is a commitment and coordination meeting for the entire team. It is designed to ensure that the entire team is aware of impediments, what stories are done or not-done, and what tasks are ready to be pulled from one team member's to-do list into someone else's.
None of the above means that a Scrum Master or Product Owner doesn't gain value from the meeting. A well-run daily stand-up will give the Scrum Master a clear picture of any process issues and whether individual stories are done or not-done. The Product Owner gains a sense of whether there are risks to the current Sprint Goal, timely insight into backlog grooming tasks for the next iteration, and provides advance notice of when a Sprint might need to be terminated early.
It is important that the Scrum Master and the Product Owner be active participants in the stand-up, but if the team is reporting to either of them, then the team is neither self-organized nor empowered to efficiently deliver value.
Your Process Might Be Broken If...
Here is a short list of "project smells" that seem related to your issue. It's part of a longer list I came up with for reference when I'm doing Scrum training for teams or when I'm coaching other practitioners. If any of them seem applicable to your situation, then your team may want to take the issues on-board during a retrospective.
- If the team has so many stories on the board at once that a verbal report needs to identify the story by number, then the process is broken.
- If the team has so many stories that a glance at the board doesn't make it clear that things are moving from not-done to done in a timely manner, then the process is broken.
- If the team is so large that a glance at the board doesn't indicate who is working on what--or worse yet, requires cross-referencing with a separate spreadsheet--then the process is broken.
- If the PM's only communication about the project or with the team is at the daily stand-up, then the process is broken.
- If the PM can't construct a burn-down chart from some combination of the story board, the daily stand-up, and ongoing communication with team members, then the process is broken.
- If the daily stand-up is not serving the needs of the team, then the process is broken.
- If estimates encourage excuses or justifications, rather than refinement over time, then the process is broken.
- If the team is reporting to any one individual during the stand-up meeting, rather than cooperatively coordinating with one another, then the process is broken.
- If your process is broken, but team members don't feel free to directly address the broken process during a retrospective, then your organizational culture is broken.
- If your organizational culture is broken, and figuring out Who do we blame for breaking it? is more important than figuring out How do we collectively fix it? then it's time to dust off your resume.