.png)
Complete visibility into time & dollars spent
Create meaningful reports and dashboards
Set targets and get notified of delivery risks
Track and forecast all deliverables
Create and share developer surveys
Align and track development costs
After years of implementation and hundreds of conversations with engineering and product leaders, we’ve seen a few things and have some knowledge to share. We’ve pulled together three of the most common roadblocks that teams run into and some recommendations to overcome them to get back on track.
Challenge: Long Pull Request Cycle Times
Long pull request cycle times put delivery at risk, and, in the same vein, unbalanced pull request responsibility creates risk because fewer people are familiar with the codebase.
Start by asking yourself the following questions:
Suggestions to improve your PR Review process:
We have you covered if you’re looking for more support with how to go about creating your definition of done or would like to review Allstacks’s definition as a starting point.
Challenge: Stories & subtasks are too large, and it's hard to show progress
Your team’s stories and subtasks are too large so the team struggles to show or communicate incremental progress.
Stories and subtasks are ways to group work and monitor progress. We recommend viewing stories as a small chunk of shippable value. The usual story criteria are considered through INVEST - Independent, Negotiable, Valuable/Vertical, Estimable, Small, Testable. A best practice on subtasks is to ensure they require no more than a full day of work complete. This methodology ensures that progress can not only be seen but is also easily updated and visible. In the same light, if the tickets aren’t moving, it’s a quick indicator of a lag in progress and a potential red flag that might need assessment.
To improve the planning of tasks and stories you should ask hard questions like: Why aren’t tickets moving? Can we break this task down further? This will lead to better alignment and accountability and empowers the software engineering team at an individual level to get involved with the process.
Challenge: The team has too many commits per pull request and/or too large of pull requests.
We commonly get asked, “How do we break these (pull requests and commits) down into smaller, easier to deliver and manage pieces?” First and foremost, it is imperative to note that pull request and commit size are independent of each other, but the ultimate goal should be to have both small enough to find direct value. For instance, a smaller commit size has an extremely high value when errors or issues arise because they can rapidly be sifted through and unwound to locate and correct the code that is unstable and/or in error.
Process suggestions:
If you’re looking for style guide reference points, we have selected a few from different companies that might spark some inspiration. Our list includes:
More from Allstacks