Mastering Professional SCRUM 3/7
Ch03. Delivering “Done” Product Increments
Improving your definition done by using Now, Next, Future technique
How to improve your Sprint Goals?
- Avoid compound Sprint Goals.
- Don’t try to micromanage with Sprint Goals.
- Make the Sprint Goal measurable.
- Ensure team consensus on the Sprint Goal.
- Create Sprint Goals that achieve business impact.
- Make it business or user focused.
- Make it focused on testing business assumptions and getting feedback.
- Make it focused on reducing risk.
Work in Progress (WIP) limit should be always set and small. of When two PBIs are in progress, a Development Team member who has availability will then focus on helping the team make progress on those two PBIs rather than starting something new.
Essentially the more things that you work on at any given time (on average), the longer it will take you to finish each of those things (on average).
Automation is often addressed in the following order:
- Version control
- Automated build
- Automated test
- Automated packaging
- Automated deployment
Here are the levels of testing
The book Continuous Delivery by Jez Humble and David Farley is a great resource for learning more about broader technical topics, including configuration management, continuous integration, deployment pipelines, managing infrastructure and environments, testing, and managing data.
- Code coverage metrics indicate how much of the product’s code base is covered by automated tests.
- Complexity metrics help the Development Team understand the degree of maintainability of the code. Examples of how to measure complexity include
- cyclomatic complexity,
- depth of inheritance,
- class coupling,
- nesting, and
- Halstead metrics.
- Build stability metrics are a leading indicator of the overall stability of the product. Can be measured by the number of days since the last red status (build failure) and consecutive red status days.
- Defect metrics provide a window into the quality of the product. Bugs.
- What should be refactored?
- How will we leave a module better than we found it (the Boy Scout Rule)?
- When we encounter technical debt in building the Increment, what will we do? What technical debt will we look for and resolve as we build?
- What will we do with technical debt that remains unresolved?
Here are some examples of capturing value in business terms by making the Technical Debt Transparent
- Refactor so there are fewer pathways through the code, reducing time to test by 30 percent.
- Apply consistent naming and structural conventions, allowing team members to be more effective and more efficient when building new features and fixing issues.
- Centralize the business logic for Feature X, making it easier to update the business logic in the future, and reducing the likelihood of bugs. In the last 4 months, we have had 24 bugs that directly impacted customers and resulted in loss of $100,000 profit.
- Refactor Feature Y, increasing the performance of the system by 35 percent, and resulting in a transaction time improvement of 2.5 seconds.
- Refactor Feature Z so that, now the customer viability has been proven, we will be able to scale the solution to a broader user base, leading to more revenue.