Delivering and Team Commitments

I was chatting with somebody today about what to do when the product of a user story does not match the original author’s intent. In these moments, it can be frustrating as a leader and the temptation can be to become more prescriptive. Likewise, the engineer can feel frustrated that they weren’t given enough information. But this doesn’t scale and isn’t especially desirable. A leader’s #1 job is to set up each team member for independence and success. BUT, of course, something’s missing there. So what to do? The conclusion that I’ve come to is to set my own expectation to create user stories that are as clear as possible in the Definition of Done and Acceptance Criteria as possible but as sparse as reasonable in the description. Of course, the amount of detail that’s needed will vary from team to team and engineer to engineer, but the principle of giving freedom within the bounds of guardrails is well established. The question I ask myself is: are there any expectations I have for the final product? Of course, functional performance will be part of the Acceptance Criteria, but do I expect a specific template to be used? Is there a new engineering pattern that the team is adopting that you want the team member to leverage? Put them in! It’s not micromanaging, it’s setting people up for success. Then as time goes by, some of the nonfunctional requirements can be promoted to the team’s standard Definition of Done but, for newer team members or newer practices, it never hurts to have the reinforcement!

Of course, this only works if the engineers taking the story actually refer to the story regularly and are disciplined in adhering to the scope of the deliverable that is committed to by the team. And that’s the key thing to consider: if a story is taken into the Sprint, it doesn’t belong to the engineer doing the work, it belongs to the team, and the team has effectively delegated that story to the engineer who picks it up or to whom it is assigned. Successful completion of the story doesn’t lie with the engineer, it lies with the team. If the story fails to complete, that’s a miss for the team and the team should look at what went wrong. Did they not support the engineer adequately? Was the story brought in without enough understanding of the work? Frequently the cause is that the scope of the work changed. But was the team consulted? Did they have an opportunity to adjust or swarm? If the engineer decides on their own to do work that’s outside of the scope of DoD and AC, then they’re effectively overruling the team. They’ve decided that the work the team agreed to do was incorrect. Sometimes it’s true that the scope of the work really has changed, and the engineer should talk with the team as a whole (typically in a Sprint standup). Then the team can take the decision to adjust the scope of the work - as is appropriate for work that is committed to by the team. Or acknowledge that the work isn’t possible to be completed, but then at least there are no surprises at the end of the sprint and the team has already become aware of a situation that might benefit from some discussion in the retrospective.