Spike

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.

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.