DEV Community: Jeff Stephens

One thing developers can improve in their next sprint

Jeff Stephens — Fri, 22 Jan 2021 14:48:44 +0000

I’ve held many roles within the agile software development lifecycle, from developer to architect to scrum master. The one mistake I’ve seen developers commit over and over again is not including a sufficient level of detail in their user stories.

Here’s a real life example of a user story I saw at a recent sprint review, “As a user, I want edits to be reflected in the data, so that I don’t need to refresh.”

I get it. Developers want to develop and they don’t necessarily want to write about it. But, looking at this example, a number of questions arise. What edits? Which data? Refresh what? Unfortunately, that was the extent of information available for this user story, other than the point value assigned and the fact that it was considered done. Good luck to anyone trying to validate that.

Why this is problematic

This is problematic for many reasons. During the sprint, your team will be flying blind as no one will be able to remember the nuance discussed during sprint planning and no one will know what is going on with the story other than the creator or the developer who is working on it at the time.

Given this lack of team visibility, there is a real chance that changes made may impact other components and team members. Developers and testers should be able to pull up the scum board and quickly understand what other work is in progress and how it might impact their work. When your user stories are ambiguous there is a real opportunity to introduce bugs, cause friction in the team, or force future rework.

When it comes time to demonstrate the functionality at the sprint review, you are also leaving your product owner in the dark. They will be lost as to what is supposed to be happening and won’t be able to understand the feature’s value. Your scrum master, and in some cases the actual developer, may struggle to remember the functionality being presented to the stakeholders at the time. This is not a good look and can create an embarrassing situation for the team and pummel your collective credibility.

Lack of details in your stories also limits any historical traceability or understanding of how the product evolved. When revisiting these user stories in the future there will be no context as to the purpose of the functionality or how it was resolved.

At the end of the day empty user stories represent poor systems engineering practices, reflect poorly on your professionalism, and provide no lasting value to the product or team.

How you can fix it

With all of that said, what you can do to fix the problem is quite easy. You simply need to write more. Provide sufficient details where anyone would be able to pick up the story and understand what is going on.

Think of the problem or feature you are addressing, especially through the lens of an end user. Consider what you would be doing when interfacing with the system at that particular point in the workflow? What would your expectations be as a user when you take a particular action? Be descriptive and think about the who, what, when, where, and why of the functionality. Reference specific UI elements or data sources that are being modified and try to explicitly walk the reader through what is going on.

You don’t need to add robust technical details as the user story is intended to mainly address the business need. The technical details will be worked out by the developer when meeting that need during the sprint. Which brings up another element needed for solid user stories, a resolution.

When you finish the story, add some information as to how you implemented the feature. Again, I’m not saying you need to write a novel but someone should be able to quickly understand what was requested and how it was accomplished.

Also keep in mind that user stories are living documents that may be updated throughout the life of the sprint. Add details or clarifications to the description as you move through the sprint. It’s better to have more details than to be left with emptiness at the end. Just make sure you don’t change the spirit of the user story as that represents the agreed upon functionality requested by the product owner.

In conclusion, in order to be considered a professional developer and one who is respected for their work product, it’s necessary to demonstrate your acuity through your lasting trail of documentation. Only then will your team take you seriously and opportunities may be presented for growth. It’s such a small change but one which could position you for real advancement.

4 mistakes you don't know you're making as a tech lead

Jeff Stephens — Tue, 19 Jan 2021 14:42:48 +0000

When you are a tech lead there's no doubt that you have a lot on your plate. You not only have the responsibility of setting the technical direction for your team, but you also need to be in control of managing them. This includes the non-technical and less sexy parts of software development like managing the team's schedule, addressing issues with individual team members, working with leadership across the company, reporting status to internal and external stakeholders, responding to way too many emails, and generally keeping things from running off the rails.

As you work feverishly through the daily churn of what seems like unrelenting requirements and responsibilities, it is understandable if you fail to realize some of the mistakes you might be making. The real problem arises when these mistakes go on for too long and end up burning your team members out or generally sapping their motivation.

Let’s take a look at 4 areas where you may be slacking as a team lead.

Not sharing down

You may not realize it but you are in the unique position of being a leader within your company. Of course your level of leadership depends on the size of the company and your overall position, but you are still at least one or two rungs higher on the ladder than your team members. As a result, you have more insight into the company’s vision, awareness of potential business pursuits, and visibility into what other teams at the company are working on. This is the type of information your team not only deserves to know about but is also something that will help them thrive.

People love to feel like they are a part of something bigger than just their singular task for the day. As a tech lead it’s your responsibility to be the company messenger in order to keep them informed and as a result, inspired. Let them know about business pursuits that are in the pipeline. Give them opportunities to learn about the great work being done by other teams within the company. Share information, both good and bad, that you receive from leadership so they become more invested in the company and develop a sense of belonging.

Not giving kudos

This may seem like one that you feel you have under control but most likely you aren’t sharing the love enough. It’s important for you to recognize the work being done by your team members and in particular letting others within the company know about it.

Use the company’s #kudos Slack channel and recognize the extra work put in on a feature by one of your developers. Post a quick message in the channel for the tester on your team who found a nasty bug before deployment to production, or the UI/UX designer who was able to eliminate extra clicks, and as a result, unnecessary items from your backlog. If you don’t have a #kudos channel or similar mechanism for sharing, create one.

It’s time you start recognizing the hard work your team is putting in. I’m not lobbying for random hollow shoutouts for somebody who is simply doing their job, but I am saying you need to recognize those that put in the extra work beyond their daily tasks. Also, make sure you keep track of the kudos you give, or record it directly in your company’s HR system. This makes it much easier when it comes time for their performance review to remember all the wonderful things they did throughout the year.

Not checking in on them enough

It’s important for you to check in on your team members, and I’m not talking about haggling them about their status or micromanaging them. I’m talking about genuinely checking in with them to see how they are doing and if they need anything.

With COVID-19 and the onset of 100% remote work, many people feel isolated and detached from their team. Reach out from time to time to say hi and see how they are doing. This could be a simple Slack message or a quick email. You could also set up recurring one-on-one meetings with them every couple of weeks for something more formal and consistent. It’s your responsibility as the tech lead, someone who they look up to, to make sure they know it is safe to talk with you at any time and that you’ll be there to listen and help however you can.

Not treating them like adults

With all that I just said about checking on your team members, you still need to treat them as adults. There’s no need to hamper them with continuous questioning or to constantly ping them for their status. They are grown folks who need to be responsible enough to manage their tasks.

You may feel like you don’t have full control and awareness because you can’t physically walk by and see them working. It's natural for you to wonder if they are watching Netflix or playing Fortnite all day, but there is a level of trust you need to establish with people.

Treat them as adults and give them the necessary room to do the work. Start with a basic level of trust and let it flex up or down based on their outputs. If issues arise, address them and manage the situation moving forward. As long as they are getting their work done, who cares how they did it. Give your team the independence they need to excel in their own way.

In conclusion, you serve as a bridge between the business of the company and the day-to-day technical delivery. To excel at both you need to maintain genuine engagement with your team, lobby consistently for them, and trust that your transparency keeps them informed and ultimately inspired.