The TMD Task Hours Estimation Process
Once the selected Sprint Backlog User Story have been assigned a “Level of Effort” story point that represents the “Complexity of Development” then the story point value must be estimated into development hours.
The development responsibilities of any given story point is always assigned to a developer with the skills and experience requirements discovered during the Sprint Story Point Estimation Process.
An estimate is not a commitment to deliver in the time estimated: It is an Estimate!
No One Tracking Actual Time for each Task
… Should be Compelled to Compare Actual Time to the Estimates
…… These kinds of Traditional Project Management Techniques Spawn Failure
No one is should be held professionally accountable for task estimates. This required accountability causes “Estimate Apprehension” and no one will give realistic estimates.
When a Developer accepts a task
and they feel the task estimate is way off
the developer should be empowered to re-estimate
the task based on their skills and experience
No Single Developer on the Development Team “Owns” any Development Task
… The Entire Development Team owns all the Sprint Tasks
…… They have all “Signed Up” for the Success of the Sprint
Unexpected things will happen that affect the development task estimate. Development Team members cannot be accurate predictors of the future.
Developers must feel safe that they can seek development support if their lack of development skills or a flawed thought process has caused a task estimate to be incorrect.
as a Development Coaching process
The rewards for the engagement are substantial!
Sprint Development Capacity
The available Development Hours within the upcoming Sprint is referred to as “Sprint Capacity“.
Sprint Capacity is part of the Sprint planning process.
Each Development Team member contributing to agrees to a fixed number of hours a day that they will dedicate to assigned Sprint tasks items.
Capacity hours range from part-time capacity of three hours a day to a full-time capacity of seven.
The Development Team Lead and Scrum Master Must Understand
… The Daily Scope of a Developer’s Company Responsibilities
…… And Accept Capacity Hours that Supports the Daily Business Processes
The below list defines some constraints to developer’s Sprint Development Capacity hours.
These constraints can pertain to required company daily activities and collateral Development Team roll assignments:
Required daily meetings outside of the Sprint Stand Up meeting
Company related support activities such as Production Support responsibilities
Rotating Sprint assignments such as Development Lead, Code Review Manager, Code Review Lead, Code Technologist and Continuous Integration Manager
New Developer ramp up Sprint
Corporate training requirements
Cross Agile Team support such as developers supporting Architect, Business, QA or Network infrastructure Team activities
Sprint development hours can be assigned to a development team member and accepted by that developer during the Sprint Story Points session or at a follow-up meeting.
If possible, the “Points to Hours” assignment should be done after consensus is formed for a given Story Point effort as at least one Development Team member has been identified as possessing the skills and experience to complete the Story Point during that session.
The most efficient process is to assign the task at that time.
The Sprint “Velocity” is defined
by the number of Story Points
completed within the Sprint iteration
Capacity and the Sense of Well-being
One of the most powerful aspects of a well-designed and executed Sprint iteration is the ability to create an environment where the Developer Team never feels like they are “Running to Catch Up”.
In traditional the “Waterfall Methodology” pressure from Management and the lack of a true “Definition of Success” create the development adversary of “The Fear of Always Being Behind”.
In the Waterfall Methodology the Developer comes to Work …
… With a Psychological Expectation of Failure
…… Do to the Lack of Clarity for a Successful Day’s Work
The Sprint development paradigm fosters an environment of creativity by defining development success day by day.
Development capacity defines the tasks by hour that a developer is required for the day’s success.
This creates the “Definition of Success” for each day’s activities.
The Sprint developer reports yesterday’s success at the Sprint Stand Up meeting the next day.
A Sprint Block is raised if anything has prevented completion of yesterday’s success criteria.
The Scum Master works with the developer to solve the Sprint Block.
This process creates a “Safe” development environment.
Developers are Never More than 24 Hours Behind
… In Any Assigned Development Task
…… And Feel Empowered to Seek Help Quickly
The Scum Master can take actions to prevent an “Issue from Becoming a Problem”
The Development Team member can put their head on
their pillow at night feeling that they have been a
successful team member that has actively supported
the engagement’s success criteria
The Sprint Development Capacity process and the Daily Stand Up meetings fosters a strong professional Sense of Well-being.
Spike Tasks and Tracer Bullets
There will be times during the Task Estimation process where it becomes clear that the team does not have the skills to complete a required Story Point effort.
In the Agile Methodology there is the concept of Spike Tasks and Tracer Bullets.
The Web Definitions of Spike Tasks and Tracer Bullets
- A time boxed period used to research a concept and/or create a simple prototype.
Spikes can either be planned to take place in between sprints or, for larger teams, a spike might be accepted as one of many sprint delivery objectives.
Spikes are often introduced before the delivery of large or complex product backlog items in order to secure budget, expand knowledge, and/or produce a proof of concept.
The duration and objective(s) of a spike will be agreed between the Product Owner and Delivery Team before the start.
Unlike sprint commitments, spikes may or may not deliver tangible, shippable, valuable functionality.
For example, the objective of a spike might be to successfully reach a decision on a course of action.
The spike is over when the time is up, not necessarily when the objective has been delivered.
- Tracer Bullet
- The tracer bullet is a spike with the current architecture, current technology set, current set of best practices which results in production quality code.
It might just be a very narrow implementation of the functionality but is not throw away code.
It is of production quality and the rest of the iterations can build on this code.
The name has military origins as ammunition that makes the path of the weapon visible, allowing for corrections.
Often these implementations are a ‘quick shot’ through all layers of an application, such as connecting a single form’s input field to the back-end, to prove the layers will connect as expected.
It must be understood the a Spike Task is a “Time Boxed” assignment.
When a Sprint task is created as a research project a fixed amount of time must be assigned to prevent the “Research Rat Hole” effect.
Likewise when the research produces enough information to create a Spike Proof of Concept (POC) in must be “Time Boxed”as well to prevent the “POC Rat Hole” effect.
The Spike ends regardless of actual completion.
The task is then estimated with the enhanced knowledge gained by the Spike process.
Food for Thought: Tips for Task Estimations
There are many ways that the estimation process can “Rip Failure Out of the Jaws of Success“.
Even the best intentions can have negative consequences.
Below are some tips the Agile community has posted to help the Task Estimation process produce positive results.
Tip #1: Create a Safe Estimating Environment – Ensure that accuracy through honesty is valued. If Developers feel threatened by their ideas and comments the entire process is threatened.
Tip #2: Break Tasks into Durations that do not Exceed the Daily Capacity of the Developer – One of the proven keys to Scrum success is the ability for the developer to define success on a daily basis. Smaller tasks, even less than a day, fosters a more creative environment as the Developer feels success on a regular basis: “Success Breeds Success”.
Tip #3: Clearly Define the concept of “A Day’s Work” – During the Sprint Planning Process the developer accepts a Capacity number for the Sprint. This number represents “A Day’s Work”. This number, as detailed above in this post, must be adjusted to all the activities and responsibilities that the developer has outside of the heads down coding of development tasks. This Capacity number may only be three hours a day. Three Hours is that developer’s day’s work.
Tip #4: Understand that Development Effort is not Necessarily Duration in Time – Most development is not a linear activity. Task estimations assume 100% of the effort to complete a given assignment but rarely is a developer able to spend every second of their Capacity working on a task. Task Dependencies, phone, email, instant messages, bio-breaks and colleague interruptions are part of the real world. A developer must be able to “Zone In” on the task requirements and often these disruptions require some time to get back “Into the Zone”.
Tip #5: Create an Environment for the Developer that Fosters the “Zone In” Concept – An estimate must be predicated on the belief that a creative environment exists for the Development Team. Each developer is a unique human being and as a unique developer has their own definition of a creative development environment. Seek out the personal criteria for each of the Development Team’s developers and help them create their productive space as much as possible. This will greatly aid in the success criteria for the engagement.
Tip #6: Be Open to Re-tasking During a Sprint, When Required – An estimate is just that: An Estimate. Being open to changing the estimation of a task when more information is available goes to the core of the Agile iteration methodology. This paradigm of thought during the Estimation Process prevents the “Paralysis By Analysis” syndrome. If the team knows that tasks that my need work to clearly define can be accepted it will take far less time to estimate the Sprint tasks.
Tip #7: Developers Do Not Own Tasks: The Development Team Owns the Tasks – It is really important for all of the Agile Teams including the Business Team that the responsibility of the development of any single task is the responsibility of the Development Team, not the currently assigned developer. All members of the Development Team must understand the abstraction of the Sprint tasks. During Code Review the Code Review Lead and the designated Code Technologist become the “Depth of Concrete Knowledge” developers of the concrete implementation of the code base under review but all team members must be aware of the purpose and definition of the Sprint task.
Tip #8: Simplify the Task Status Definition for Clear Communications – When discussing the status of a given task limited the status types to three: TO DO, IN PROGRESS and DONE. These terms can be modified for the given culture but the concept should be adhered to. This helps prevent ambiguity such as “I am 60% complete, I think” or “Yea, I have been thinking out it so let’s say 10%”. On a Sprint task board or Agile application there should only be statuses that represent only the concepts of Not Started Yet, Started But Not Completed and Completed and Ready for the QA Team.
Tip #9: Use a Burn-up Chart Rather Than a Burn-down – As detailed above the Sprint Metrics can be misleading using the traditional Burn-down approach. Sprint re-tasking and Scope Creep by the Business Team will not be accurately represented in a Burn-down methodology. The Burn-up process separates out the changes in scope from the actual tasks completed. Additional tasks are not represented as failures to burn down; they are represented accurately as additional successes in the Sprint. Scope Creep is accurately represented as a raising and falling line graph.
Tip #10: Update Task Status as Soon as the Task is Deemed Completed – The Agile Teams need to be able at any point in time to evaluate the current state of development. By creating a personal discipline to update your statuses of task as soon as they are ready for QA you help foster a sense of progress for the Stakeholders, Product Owner, Scrum Master and Project Manager.
Tip #11: Internalize the Value of the Ubiquitous Language – The Task Estimation Process offers an excellent opportunity for the Lexicon Master to validate that the tasks comply with the terms and the definitions within the Ubiquitous Language. All task development naming conventions but use the agreed upon terms so that all Agile Teams understand the delivered Products with the same “Lens of Understanding”.
Tip #12: Understand the Value of “Spike Tasks” and “Tracer Bullets” – When during the Task Estimation process it becomes clear that an understanding of the complexity and required effort of a Story Acceptance Criteria is vague or completely unknown a research task along with a Proof of Concept (POC) task should be created. These “Spike Tasks” will save time and money over assigning a vague task to a developer. It is possible to create POC code that can actually be Production quality code base. These are referred to as “Tracer Bullet Code”. After the research for a Spike is completed and before the POC begins a decision must be made by the Development Lead and Architect Designer as to whether or not the POC will become a Tracer Bullet or “Throw Away” code.
The success of the engagement development process is predicated on the Scrum Master acting as an “Anti-corruption Layer” between all opposing Software Development Forces that could adversely affect the “Heads Down Coding” efforts of the assigned developers.
Dynamic management of these forces will help to ensure that the Development Team performs in an efficient and productive manner.
Daily awareness of the forces will foster a strong sense of well-being and pride within the development team.
They will be confidant in the quality of the product that they are delivering each day of the engagement.
It is the responsibility of every team member
to be proactive everyday in fostering
a creative development environment
Wisdom Pearl # 129 – The Architects Sandwich
How Do You Eat an Elephant
… One Sandwich at a Time
The Epic User Story is Your Elephant
… The Related Child User Stories
…… and their Grandchildren Stories are your Sandwiches