Are they the seeds to be nurtured to bring in automation, innovation and transformation. There is a saying, necessity is the mother of invention. I would say, innovation is amalgamation of creativity and necessity. We need to understand the ecosystem, to apply creativity and identify the ideas to bring in change. We need to be competent with changing ecosystem and think beyond the possible. What is the biggest challenge in doing this? "Unlearning and Learning", we think the current ecosystem is the best. Be it health, finserve, agriculture or mechanical domain, we need to emphasize with the stakeholders, to come up with the strategy to drive. The very evident example here is the quality of life is changing every millisecond. Few decades back the phone connection was limited to few, but today all the millennials are having a mobile phone. Now phone is not just a medium to talk, but are so powerful devices that an innovative solution can be developed on it.
Hello All,
Over last 5 years IT industry had changed with a very fast pace. Industries are going through a Disruptive Evolution phase where Agility is the key to success irrespective of domain. Wherever I had implemented Agile, it made me think What is Agile?
AGILE is “Art of Grooming a product using Intelligent Lean Engineering”. - AG
Agile or Scrum is not new they still holds the same charisma as it had three decades back when it was first introduced. Decades back it helped crack plenty of uncontrolled subjects in the space of management. Agile practices had evolved overtime. Agile communities and followers had given varied flavors to Agile, for community to consume it and be FrAgile. Organizations and Leaders had invested in Scrum with an objective to gain AGILTY.
In various forums, discussion had happened around execution part of Agile which is Important however estimation techniques used in Agile were not given enough importance. There are techniques which can help outline Agile estimation and enable Scrum masters to be Lean and Nimble during the SCRUM JOURNEY. In this blog, I will try to provide additional insights as to how we can mature Agile Estimation practice. At this point, Scrum masters, Lead and Team members looks at estimation as “How long will it take for a team to delivery User Story?”. Maturity of individual, Estimation Tools and most important harvesting from previous sprint, how these factors can help refine benchmark Velocity for future sprints. Level of confidence that User stories will be successfully completed ON TIME will change over time from Low to High.
There are various techniques available as listed below which are commonly used for Agile guESsTIMATION and all these techniques are invariably used across projects. That said, I had used Pocker card, T-shirt sizing and PERT estimation techniques for most of my assignments in past.
- Planning Pocker card estimation.
- Three-point estimation.
- PERT techniques
- T-shirt sizing
- Wideband Delhi technique.
- Law of averages.
Despite these well-defined estimation techniques, “Why most of the Scrum teams struggle to complete planned user stories count in the respective sprint?”. Below is the list of top 5 reasons for their struggle.
- Lack of clear definitions around EUT components (EPIC, User stories & Tasks)
- Fail to decompose User Stories into a reasonable and manageable sized task
- Definition of Done (DoD) is not well defined
- Scope of work dependency for estimation.
- Dearth of estimation tools.
What is the common factor among all Top 5 reasons for Agile to go Fragile and out of track? Aren’t they all revolve around ESTIMATION and reflect Agile Estimation Maturity practices. Lack of adoption of statistical drive Agile estimation tools led to absence of Predictable and Consistent estimations. At last we are now aware of the problem area so let us focus on how we can improve our Agile Estimation practices. Emphasis will be on each reason listed above and how to overcome shortcomings.
First Reason: Lack of clarity and clear definitions around EPIC, User Stories and Tasks:
An Epic is defined as a large enough requirement that helps define Minimum Viable Product (MVP) from Customer perspective. It is an abstract definition of what stakeholders/Customers would like to action or process. For example, customer comes back and say I would need a system to track vehicle sales.
User Story can be defined as story which has very precise action statement that helps product inch towards a step close to what is defined in EPIC action. Multiple user stories form an Epic. For example, customer’s Epic where she wanted Vehicle Sales Tracker, it can be broken down into multiple User stories like 1) Tracker which allows sales people to log into the system 2) System should provide individual a dashboard to track their Target, inventory and Sales for a day, week and Month. 3) System where Individual can update sales real time with customer details and so on so forth.
Task is defined as immediate action that Scrum team takes to deliver Minimum Viable Product. For example, Individual story is broken down into task(s) for each team members to work on. If we consider 1st user for logging into the system. Tasks could be 1) Create UI for individual Login 2) Add Validation for User and Password field 3) On submit connect to credential authentication system and confirm user’s Authentication and Authorization.
It is important to be CRYSTAL clear on definitions and understand what is the key difference between each Agile EUT component. EUT is based on the principle that Tasks provides MICRO view of Epic provides MACRO component. EUT helps understanding the definition of Minimum Viable Product (MVP). It is recommended to adopt both Top down and Bottom up approaches in the initial 20% - 40% of sprints to have 90% to 95% Confidence of delivering MVP.
I had personally recommended T-shirt sizing approach for User Stories and PERT or Three point for Tasks.
T-Shirt estimation help understand at macro level size. This is Tops Down approach.
PERT (Program Evaluation and Review Technique) is one of the most common technique used for estimation, it started way back in 1950s. PERT is all about probabilities hence we have 3 probabilities i.e., Most Likely (M), Pessimist(P) and Optimist(O). This is bottoms up estimate technique @ task level.
Estimation = (Optimist Estimation + 4* Most Likely Estimation + Pessimist Estimation) / 6
E = (O + 4*M + P)/6.
Key to the success is to follow these approaches for few sprints but keep adjusting these factors based on lesson learnt from previous sprint estimates.
Second Reason: Fail to decompose User Stories into reasonably and manageable sized tasks.
As a guiding principle that I suggest for any Agile project should be Maximum a day and minimum 2-3 hours. Try to break down Tasks into independent task for individuals, never ever club tasks for 2 or more in task in a single task. Let me take an example of Software Industry where build phase developer has a task for Coding, Code Review and Unit Testing. One of the common mistake most of scrum masters do is not coaching individual to break these activities into 3 different tasks. Code review is typically done by third person and not an individual hence merging 2 individual tasks will become a bottleneck for tracking progress. Having said that, define what suits Scrum team. Scrum team’s maturity is one of the key factor that will help us decomposition. Team’s maturity is directly proportional to appropriate level of decomposition.
Third Reason: Definition of done is not well defined.
“Definition of Done”, it is analogous to “Acceptance criteria” or “Exit Criteria.
- Is it only relevant for development and testing team? Answer is “No”, It is so much relevant for all actors starting Product Owner, Scrum Master, Business Analyst Developer and Tester.
- Is it mandatory to have “Definition of Done”? Answer is “No”, It is not mandatory however it is one of the best practice that one should adopt.
- Does it have any drawback to adhere to “Definition of Done”? Answer is “Yes”, never ever fixated with the DOD checklist. Agile is all about agility and hence need to be flexible enough to make sure team is not fixed.
Definition of Done should be agreed upon by everyone at various stages of Agile to avoid fascination for criteria ONLY.
Fourth Reason: Scope of work dependency for estimation.
Well defined scope of work is such a broader term and it is no brainer how important it is for the success of any Program or Project. Enough attention should be given to the dependencies, which is very critical. I had touched upon the importance of PERT while explaining first reason details. Let me explain, the concept of PERT.
PERT helps define Schedule, Dependencies, Parallel Tasks and Concurrent tasks. PERT help us identify “Critical Path”. While doing the Release planning or Sprint planning after task are defined, try to list if task has is the “Start Task”, “End Task”, “Preceding Task”, “Following Task”, “Concurrent Task”. Drawing a PERT chart help team understand
1) Tasks on Critical Path for the sprint, where scrum master should pay utmost attention on all task on CP. Any unexpected delay for the task on CP will potentially lead to spill over of tasks to next sprint.
2) List of tasks which are dependent i.e., list of preceding and following tasks.
3) Optimal allocation of tasks to avoid delays because of dependencies.
In the above chart, Task 4 or Task 5 must be completed before Task 7 can be started, Task 2 and Task 3 can be executed in parallel hence there is no dependency among Task 2 and Task 3. Dependencies should be handle with utmost urgency to avoid delays.
Fifth Reason: Dearth of estimation tools.
There is no standard tool for Agile estimation as Agile whole premise is to adjust velocity, estimation and other criteria customize to once suitability. Every agile team has its own maturity and characteristics like appetite to deliver. It is highly recommended that Agile estimation model should be developed by scrum master and team as they progress based on historical data.
For example:
Sprint 1:
Simple task has task been allocated 3 story points (for explanation assume 6 hours)
Actual effort spent to complete simple tasks is as follows
Task 1 – Simple – 5 hours
Task 4 – Simple – 3 hours
Sprint 2
Based on historical data from Sprint 1, average time for simple tasks is 4 hours hence simple task should be allocated 3 story points (4 hours).
OR
While doing the categorization of task, carefully assign task to Very simple category instead of Simple, which means
Task 5 – Very Simple task – 3 story points (4 hours).
To conclude benchmarking of Task categorization i.e., VS, S, M, C, VC, # of Story Points, Hours mapping to story points will get mature and refined over multiple iterations of sprints. We should track Velocity for every individual and hence allocate number of story points to an individual based on their benchmark data. Scum master should never be tempted to allocate same number of story points to all.
With this let me sum up my thoughts around top 5 reason for errors in estimations and what best practices and guidelines we should adapt to minimize those error or deviations. As stated earlier, these are mere guidelines so one should take these recommendations with the pinch of salt. Like No two individuals will ever be same, hence dynamics for 2 projects will never be exactly same. Adopting best practices will increase chances for us to be 95% confident of accurate estimations.
We are what we repeatedly do; excellence, then, is not an act but a habit. — Aristotle
Thank you,
Outstanding Outlier:: “AG”
Comments
Post a Comment