Team Effort Estimations Are Critical to Accurate Velocity, Maximum Productivity, and Team Building.
The team tech lead may provide an effort estimation with little or no input from the developers and/or testers doing the work.
If the tech lead vocalizes his/her effort estimation…
- BEFORE the developer who will be doing the work, the developer may feel pressured to agree with the tech lead’s estimate.
- lower than the developer’s guestimate, who will be doing the work, this might create social friction and inaccurate velocity.
- WITHOUT a collaborative approach, a comprehensive estimation may be ruled out, such as consideration for not only dev. and test., but infra (configuration management, i.e. build & deploy) and other effort costs.
Using tools like Planning Poker, where all estimations are revealed at once helps the team appear to not contradict one another. The negotiation process occurs after all teammates flip their cards at once. Derives better estimates with more perspectives not factored in based on a single Tech lead providing the estimation.
Transparency and Scrutiny
Many “hands-on” project/product stakeholders want maximum transparency into the current state of the product regardless of the duration of the sprint (e.g. 2-week sprints), Typically, a pulse on the product at two-week increments satisfy most.
Some of the agile, change management tools such as Microsoft Azure DevOps offer dynamic graphing and reporting. Product stakeholders may be provided dynamic dashboards, that include Burn Down, and Burn Up charts based on the sum of effort from user stories (i.e. product backlog items). At any given time charts can predict velocity, and based upon the outstanding, total effort estimation, can chart a course to the next release.
Meaningful burn up and burn down charts rely not just on accurate effort estimations, but the people who are assigned these user stories constantly update the status of these stories, e.g. New; In-Progress; In-Review; Done. Countless times I’ve seen team members update the user story status the day before the sprint close/demo, from New -> Done. This habit gives any product stakeholders a false view of the product within a sprint.
Another challenge and opportunity with Transparency and Scrutiny within a given sprint, is making sure each user story has one or more (child) tasks. Defining tasks provides a wealth of opportunity, such as naming all of the tasks to complete for the story, e.g. database tasks, UI tasks, etc. If the tasks are itemized, they may also be assigned to multiple team resources, and show a delineation of labor.
Sticking with the Azure DevOps tool, Tasks have a default field, “Remaining Work”. This field may express task work in hours or days, the unit of measure. In the beginning, tasks are populated with the total task guesstimate of hours. Each day the person assigned the story task may draw down on the task to incrementally show progress within the task and correlating story.
Task, Work Remaining field must be relentlessly updated across the Backlog in play or else it will create more harm than good. At this level of scrutiny on tasks are amorphous and will be challenging to garnish any projected value.
The Abominable Blocker
What, you can’t figure it out on your own?
The dreaded blocker has the ability to stop a Scrum team in its tracks. The term Impediment used synonymously with the word Blocker, has an innocuous sounding sentiment. Your Scrum team may use either, perhaps a less severe issue merits an Impediment?
The Kanban / Scrum board may have a column in the workflow called Blocker, which should fixate your team on helping to remediate that Blocker. Our Daily Scrum of 15 min may focus on Blockers as they have been isolated in our workflows.
Conquer the blocker before it conquers you!
Closing and Demo for Sprints should follow healthy applause from the team, including Stakeholders and Product Owner. Positive reinforcement of a job well done. We’ve completed what we committed to complete, should be followed by applause. We should take a moment to soak in the feedback.
Pass the Mic
For those of us on the Scrum team who are introverts and actively look for ways of dodging opportunities to speak, this one is for you. During Daily Scrum, pass the facilitation mic around where everyone gets an opportunity to facilitate per stand up.
Allow all people within the team an opportunity to demo the “Done” user stories on sprint close. It’s not to break folks out of their shell, it’s to impart a sense of pride in the work accomplished, and truly resonate the one team mentality.
Disclosure: the opinions provided are my own and do not reflect that of my clients, or anyone I represent.