How do you track project progress? Key Performance Indicator. KPIs are:
- Quantifiable measures
- Indicators of success/fails
- Semantics need to be defined per context
These could be things such as system uptime, income, returning visitors.
Metrics:
- The team must understand the metric
- The team must collect the data
- The metric must have value to the team
- Collecting the data should require little effort
Every Agile framework has its own set of metrics. Lean measures execution time; kanban on task flow; scrum on the team’s ability to deliver.
Monitoring Code Quality
Pair Programming
Pair programming is a great way to ensure high code quality and monitor task progression: the code you write is a reflection of the team dynamics.
Code Review
Review the code for:
- Invalid operation definitions (e.g. too few/many arguments) or usages
- Missing comments/documentation
- Missing unit tests
- Code quality
- Number of files, classes (e.g. god classes), LoC
- Code duplication
- Documentation/comment rates
- Code smells/technical debt
- Input sanitization
Sprint Reviews
The very last moment where you can track progress. Ask the PO before the review if necessary.
Semi-Automated Tools
- IDEs (e.g. IDEA)
- Linters (e.g. ESLink)
- Static analysis (e.g. SonarQube)
Automated checks:
- Enforce common style
- Refactor common patterns
- Identify possible bugs
Aggregated vs simple metrics:
- Aggregated metrics are a overview of the quality:
- Reliability: number of issues classified as bugs
- Security: number of vulnerabilities (e.g. XSS)
- Maintainability: number of code smells
Simple metrics for targeted aspects:
- Coverage: % of code covered by unit tests (e.g. num. lines, num. branches)
- Duplication: % of duplicated code
- Comments: proportion of comments
- Code-related: e.g. cyclomatic complexity, class/method size
Refactoring and Re-engineering
Refactoring increases code quality:
- Changes a function without altering its output (e.g. extracting part of a function into a private method)
- Should be done incrementally all the time
- Should be low-risk and part of day-to-day tasks
Re-engineering fixes behavioral issues:
- Re-thinking the behavior of a part of a product (e.g. moving business logic to another component)
- Should be planned carefully
- Is a high-risk activity
Team Dynamics
Communication:
- Day-to-day communication can act as a metric for the working atmosphere
- Ensures commitment and accountability
Stand-ups:
- Daily monitoring of progress; identify roadblocks as they arise
Retrospectives:
- Safe place to debrief
- Collaboratively think about improvements
Sprints and Releases
Burn-down charts: graph mapping days remaining until end of sprint against remaining story points (or possibly hours of work left).
Alternative release burn-down chart:
- To predict number of sprints until release - bar chart with bar for each sprint.
- Scope likely to increase each sprint.
- Top of each bar = initial story points (for release) - story points completed towards release
- Bottom of each bar = added scope
- Release likely when lines connecting top and bottom of bars meet
Sprint interference chart:
- Hours spent/sprint on non-sprint backlog tasks
- Emails, meetings etc.
- Try and ensure this does not increase over time.
Remedial focus chart:
- Velocity: number of story points completed per sprint
- Story points from scope changes should be measured separately
- Should decrease over time
- If the velocity decreases over time, your code quality is likely decreasing