Three Ways to Improve Projects Delivery and Avoid Defects.

1. Avoid scope creep by a well-fitted controlled scope that meets the delivery timeline.
2. Implement Coding best practices that seek to refactor and optimize the code throughout the project lifecycle.
3. Enough slack to manage issues. There is a 100% probability you can expect problems.

What is scope creep, and how do you discover it early to eliminate it?

The scope is the agreed amount of work to be done in a time frame at a cost. Scope creep is when the number of work increases beyond the first agreed-upon amount.

Burndown charts are the fastest way to identify if you have scope creep in your project, but how do you reduce the story points fever, burning up charts when they should be burning down?

Here are the main reasons for scope creep

• Poor Requirements Analysis comes in several flavors.
  • Poorly defined initial requirements, the source of this is product owner (PO) or business analyst (BA) who is unable to articulate the final output clearly. Sometimes the author may not clearly understand requirements, and the sprint begins with a “build the wings on the way down.” approach.
  • Lack of understanding of the defined initial requirements, the source of this error is by the document’s recipient and their comprehension of what they are reading. It can result from a lack of attention or lack of experience on the subject. You do not know what you do not know.
  • Developer bias and assumption can lead the developer down the wrong path. The most prevalent among the many preferences is that confirmation bias makes you unconsciously seek only information supporting your position. Recency bias puts undue importance on the latest thing you’ve worked on, seen, or read. Discrimination can be tapered with an open-minded approach and probing questions.
  • A combination scenario can be a combination of poorly defined requirements, accompanied by a lack of understanding and biases.
• Not Involving the full development team in the analysis will typically leave some uncovered scope to be caught later in the sprint. A 360-degree view during planning poker by all team members will better prevent underestimation of complexity early in the life cycle.
• A vague requirements analysis at the beginning of the sprint will lead to creep. More detailed design and development will inevitably lead to scope creep as understanding increases.
• User Verification: when the prototype is visible, the PO or BA should validate it immediately. Often, the misinterpretation becomes known, and more often than advertised, the business realizes a change in plan. It is rolled up and pushed under the carpet of a vague understanding of the developer’s requirements to accomplish the transformation. The user story was not written by the PO originally, although treated as the original scope.
• Developers are trying to please customers and adding more features commonly known as “Gold Plating” and or Customers trying to get extra work done within the agreed flat rate, so they are getting “a bang for the buck.” “Gold Plating” is a typical result of mismanaged direct contact between clients and developers.
• Unlocked Requirements: Agile is different from waterfall because waterfall protects against change in requirements, whereas agile encourages it. The commonality between the two is that during the active sprint, the requirement is locked and immutable. Since agile sprints are usually 2-3 weeks in duration, a requirement is locked for a short period and does not impact as it does for a 6-month waterfall project.

What does this look like beyond the textbook and in the wild world of agile?

1. New Stories added after the sprint starts: This can be gold plating or just misjudged complexity. This error applies to both greenfield build or current production feature release. Developers start adding stories/tasks after agreement with the scrum master, and the sprint begins. It is taboo to add a story(s) after the sprint starts. It warrants equivalent story points from a selected story/requirement.  Many teams overestimate the importance of most things. To be wise is knowing what to overlook. If we take all the tasks to be done and estimate the number of hours to get all done, we can start to see that we must eliminate some stories to get our time back.
2. HOT Fixes: This is a form of working on new emergency stories added to the current sprint feature build. Hot Fixes support a live production system; ensuring there is enough slack to manage this is important. Present bugs that come during the current sprint build will change the scope of the current sprint.
3. Current Stories change story points during the sprint: This is a flawed analysis rearing its head.  Effort and risk estimated will never be lowered but only raised as we gain more intelligence during the delivery.
4. Untimely updating of Story Cards can be due to dependencies on other stories. Chaining Stories is a form of increasing unseen and unexpected complexity.
5. Tool usage and process; the story’s status is trending to closed or resolved impacts the burndown status based on the tool you are using. Mastering your story processing and reporting is instrumental in detecting scope creep.

Stephen Choo Quan

Sharing is Caring. Thanks for reading and Sharing ❤

Follow me On: Instagram | Facebook | Linked in