A successful engineering squad knocks out simple, well-designed, bug-free, extensible work, with little to no tech debt, sprint after sprint. Tech specs become tickets, tickets are subtasked and pointed, and the volume of tasks in each sprint matches the capacity of engineers on the team. Tasks (small tickets or subtasks of larger tickets) typically take 1/2 day to 1 day, and are pushed to production as they are completed.
Moreover, context is king – each squad within an engineering org understands the product, and the company drivers, such that it understands how its work impacts the success of the entire Engineering department, other departments, and the entire company.
Often, this kind of well-planned, quiet, tech debt-free success is difficult for company managers, including many engineering managers, to understand and support. Worst case, C-Suite and other managers often feel their engineers are not working hard enough, that their engineering departments are not executing fast enough, unless engineers are working long hours and creating tech debt. In my experience, long hours and tech debt are not needed, and are signs that things are not going well.
Some CEOs will express frustration toward engineering managers, who will in turn “protect” their teams, by shielding the team from criticism. In my experience, this kind of “protection” is another unhealthy sign. And, that kind of pressure always finds its way all inside engineering squads. There is no need for protection, if squads operate with total transparency in all their work, such that anyone can look at current product specs, tech specs, and tickets in the current sprint, and understand what everyone is working on.
The purpose of sprints, from the point of view of non-engineering managers, is to provide a consistent, predictable quantity of work that each squad can perform, sprint after sprint. Non-engineering managers should be able to ask for work, get reasonably accurate estimates of when it will be done, and be able to rely on those estimates, quarter after quarter.
All managers, good and bad, have some sense that high performance engineering is difficult to create and sustain. Many have never experienced successful engineering departments. In this post, I’m going to explain how to operate a successful squad. It involves a level of planning and execution that might be different from what you’ve experienced in your groups, but which, with the right leadership, comes very naturally to engineers.
Leadership
Continual Success
Transparency
Generalize
Autonomy
Ask for Help
A sprint is the ability to consistently execute a predictable amount of work over each two-week period. Deploys occur continuously. Launch deadlines are calculated and tracked outside of sprint planning.
Nearly all sprint planning occurs outside meetings. Planning begins with a written product spec, followed by a written tech spec. Tech specs are assigned round-robin to each engineer, with the caveat that particular tech specs may sometimes require that a subject matter expert author them. Ideally, though, a subject matter expert will help guide whichever engineer gets assigned to write a spec. This feature of sprint planning is one example of the principle of generality: within a squad, we strive toward generality, and away from specialization.
Immediately after a feature is completed, the tech spec, along with any runbooks or other required docs, are revised and completed as required to match the performed work. The spec becomes the documentation.
The engineer who writes a spec also writes the tickets to implement the spec. Wherever possible, tickets and subtasks should be written with as little order-dependence as possible. There should be few or no “blocked by” or “blocks” tickets in any sprint. Each task should be deployable to production. Tickets should be taken in the order they are listed, and should not be assigned at the start of the sprint.
There are four types of regular meetings: Scrum (daily), planning (weekly), and pointing (bi-weekly), and manager-report one-on-ones (bi-weekly).
The backlog should contain only tickets that are ready to be worked on. And, there should always be at least two sprints’ worth of work planned, subtasked, pointed, and ready to go.
Note that there is no retro in my list. In my experience, it is best to handle problems, and celebrate successes, as they arise, rather than waiting until the end of a sprint. However, if a team feels strongly they want to have retros, that is a reasonable ask. In my opinion managers should not attend retros, but instead should take as input whatever the rest of the team wants to provide, in whatever form they want to provide it.
Deploys are continuous, unrelated to sprints, and do not ordinarily occur on Fridays or weekends.
Create a productivity feed in Slack, where the statuses of tickets, PRs, and deploys are reported in a single feed.
A daily, max 15-minute meeting, where each engineer gives a quick update, focusing mostly on blockers or potential problems, as well as any “off-the-books” work where, for example, someone from outside the squad is taking squad time. The entire team, and especially the Lead, should have a consistent, daily picture of what’s being worked on, along with any bumps in the road.
The Scrum Master leads the scrum. The product manager can pass if they have no updates.
Proper planning, including documentation, is essential for a successful squad. In my experience, many or most problems in a struggling squad can be traced back to poor planning and documentation. Each minute of good planning saves many minutes of writing code.
Ideally, there are one or two Sprint Planning meetings per sprint. I find Wednesdays to be the ideal planning day. The purpose of these meetings is to, by the end of the current sprint, complete planning for two full sprints worth of work; we always want two sprints worth of work in the backlog. If we can do that in one meeting, let’s. If not, let’s do two Sprint planning meetings per week.
Each meeting is one hour long, with a caveat below. All team members should attend Sprint Planning meetings. Prior to the meeting, all upcoming work has already been assigned to individual engineers, who should have created tech specs, gotten whatever help they needed to complete them, and have created tickets and subtasks.
Each sprint, there is one Sprint Captain. Every engineer rotates in as Sprint Captain. At Sprint Planning meetings, the Sprint Captain walks the entire team through each task, and gives the entire team an opportunity to ask questions, point out inconsistencies, and help simplify. A ticket is moved into “ready for work” status, once the entire team agrees it is ready to be worked on. If, after a few minutes of discussing a ticket, the team deems it not ready to be worked on, the ticket is marked “not ready”, the team moves on, and that ticket becomes a subject of the next Sprint Planning meeting.
Although pointing happens in a separate meeting, a good deal of effort should be put prior to and during sprint planning, to keep tickets to 1 or 2 points, as defined below. A natural callout in Sprint Planning is “Should we split this task into multiple subtasks?”.
There are a few ways to point successfully; I prefer this one.
Points are assigned in terms of risk x time:
– Bugs are not pointed – 0 points: no risk, 10 minutes, like a copy change to an HTML page – 1 point: low risk, ~1/2 day – 2 points: medium risk, ~1 day – 3 points: higher risk, 2 days or longer
Bugs are not pointed.
If we have lots of 3 point tickets, we have likely not taken the time to break down tasks into small enough subtasks, and we are behind in our planning.
The Sprint Captain reads through each ticket and subtask, and the team votes either with fingers, or in chat. Outliers are given the opportunity to give input. It’s usually best to go with the higher estimate, even where that estimate is in the minority.
The Scrum Master owns Sprint capacity planning. Each engineer has 8 points of capacity per week, minus any planned days off. This is 2 points / day, 4 days / week, leaving 1 day / week for planning, writing specs, etc. If the manager is hands-on, they will usually have fewer than 8 points, depending on their workload.
In this post, I’ve represented an outline of the best planning, process, and leadership practices I’ve found success with over the years. In my experience, it’s possible to transform a squad that suffers some combination of poor planning, low morale, messy backlog, poor documentation, production bugs, and tech debt, to a happy squad with strong, quiet, consistent output, as described in this post.