As engineers working in agile environments, we live and breathe user stories. They are the fundamental building blocks we use to understand what needs to be built. But often, a crucial part of the story gets left out, leading to wasted effort and a disconnect between our work and the actual value it was supposed to deliver.

What Exactly is a User Story?

Originating in Extreme Programming (XP) and now a staple of most agile frameworks, a user story is a simple, informal description of a feature told from the perspective of the person who wants that feature. It's designed to shift the focus from rigid, technical requirements to understanding the user's need.

A common format you'll see is ISBAT, which stands for "I Should Be Able To. For example:

As a [type of user], ISBAT [an action] so that [a benefit or goal].

Subscribe now

The Crucial Missing "So That"

In my experience as an Agile Coach, I've observed that a LOT of user stories I encounter are missing the "so that [a benefit or goal]" part. Product owners and teams often write stories like:

• "As a user, I want to log in."

• "As an administrator, ISBAT create new user accounts."

• "As a customer, I want to add an item to my cart."

While these tell us who wants what, they completely omit why.

Why the "So That" is Non-Negotiable

Leaving out the "so that" is a critical oversight. The benefit or goal is the value proposition of the user story. It's the crucial link that translates the business or customer need into something the engineering team can truly understand and build effectively.

Without the "so that":

• Prioritization is based on guesswork: How do you know which story is more important if you don't know the value each delivers?

• Decision making is less informed: The team lacks the context to make the best technical and design choices. They might build something that technically fulfills the "what" but fails to achieve the intended outcome.

• Measuring success is difficult: How do you know if the story is truly "done" and successful if you don't know what benefit it was supposed to provide?

• Motivation can suffer: It's harder for engineers to feel connected to their work when they don't understand the positive impact it will have.

The "so that" provides the necessary context for technical interpretation. It allows engineers to think about the underlying problem and potential solutions, rather than just implementing a requested action blindly.

Share Engineering Markdown

6 Categories for Defining the Value: Beyond Just Revenue

While revenue is a business goal, simply stating "so we can make 1 million dollars" in a user story is rarely helpful. The "so that" should explain the specific user benefit or operational improvement that leads to business outcomes.

Here are some categories of value to consider when defining your "so that" clause:

🔹 User Efficiency / Productivity

How does the feature save the user time, effort, or reduce errors?

As a online shopper, I want to save my payment information, so that I can complete future purchases faster.

🔹 User Satisfaction / Experience

How does the feature make the user happier, more confident, or the system easier to use?

e.g. As an online shopper, I want to see clear error messages, so that I understand what went wrong and can communicate it to customer service.

🔹 Business Efficiency / Cost Reduction

How does the feature improve internal processes or lower operational costs?

e.g. As an site administrator, ISBAT automate report generation, so that our team saves 10 hours per week on manual data compilation.

🔹 Risk Reduction / Compliance

How does the feature mitigate risks or help meet regulatory requirements?

e.g. As a shopper, I want two-factor authentication, so that my account is more secure against unauthorized access.

🔹 Increased Engagement / Adoption

How does the feature encourage users to use the product more or for the first time?

e.g. As a new shopper, I want an interactive tutorial, so that I can quickly understand how to use the core features.

🔹 Learning / Knowledge

How does the feature provide the user with valuable information or insights?

e.g. As a site manager, I want to see site usage statistics, so that I can track progress towards my goals.

Finding the "So That"

If you're struggling to define the value, ask these questions from the user's perspective:

• What problem does this solve for me?

• How will my life/work be better after this is implemented?

• What pain points will be removed?

• Why would I choose to use this feature?

• What is the ultimate goal I'm trying to achieve?

And from a business perspective, consider:

• How does this user's action contribute to a business goal (like increased revenue, reduced cost, improved retention, etc.)? Connect the user's benefit to the business outcome.

Make the "So That" a Habit

Insisting on a clear "so that" in every user story might feel like extra work, but it’s crucial in ensuring you are building the right thing and it pays dividends in the long run. It aligns the team around shared goals, leads to better-designed features, and ensures that your engineering efforts are truly focused on delivering tangible value to both your users and the business.

So… if find yourself guilty of omitting the value in a user story, start incorporating the "so that" into your user story writing using the 6 categories and questions. You’ll quickly see the difference it makes.

Sound familiar? In this newsletter I want to talk about a very common struggle I see: Little to no attendance at the Sprint Review.

What is a Sprint Review?

The Sprint Review is a ceremony within Scrum. In that ceremony the Scrum Team (Development Team, Scrum Master, and Product Owner) present the work completed in the Sprint. The primary goal of the Sprint Review is to demonstrate the increment of work done and to gather feedback from stakeholders, including the product owner, customers, and any other relevant parties.

13 issues that kill Sprint Reviews

The attendance of your Sprint Review, or rather… the lack of, is a problem that can quickly demotivate a team and de-energize the Scrum ceremony. Here are common issues I’ve encountered over the years:

1. Stakeholder unavailability

2. Stakeholder role in the meeting is not understood

3. Lack of meeting consistency

4. Demo is too technical

5. Demo of partially completed work

6. Demo with no time for feedback

7. No demo due to lack of UI

8. Context of the work is missing

9. Unpreparedness, awkward pauses or gaps

10. Progress and achievements aren’t celebrated

11. Focus on documentation over working software

12. Overly long and unfocused feedback discussions

13. Team resistance to feedback

Addressing the Sprint Review killers

As you can see the list of Sprint Review killers is long and… complicated, because:

The Sprint Review is a balance of meeting facilitation basics, professional and charismatic demonstration, and bi-directional conversation. Without these fundamentals things can quickly fall apart for a team.

Let’s dive into the killer list so I can offer some insight and ways to address the problems.

Stakeholder unavailability

Stakeholders are unavailable according to their calendar.

It’s a pain, but the meeting owner MUST take the time to talk with stakeholders to work out a time they can attend. Their calendars don’t often paint an accurate picture of the availability, so it requires additional conversation and moving a few things around.

Stakeholder role in the meeting is not understood

Given the meeting agenda, dynamics, and ownership the stakeholder doesn’t understand their place/role in the meeting.

Make stakeholder role expectations explicit in the meeting invite; something along the lines of: “Your attendance as a stakeholder is required so that we can get your feedback on our work before we commit to the work in our next Sprint”.

Lack of meeting consistency

Your team is canceling the meeting quite often.

Ensure that your Sprint Reviews are consistently happening, the consistency is easier for stakeholders to depend on. When the meeting is undependable, their attendance becomes undependable.

Demo is too technical

Developers tend to get too far into the technical weeds, losing the majority of the audience.

Ensure that the stakeholder value is being presented. Have the team practice, look for those “look squirrel” and deep dive tendencies and then squash them.

Demo of partially completed work

The work is fragmented and/or incomplete which can confuse stakeholders.

It’s tempting to show what you’ve got partially done, but if the work isn’t a thin vertical slice through your stack you’re going to lose your stakeholder on the context and applicability in the big picture. The fix… at a minimum, demo completed work.

Demo with no time for feedback

The demo part of your Sprint Review is too long and doesn’t allow time for feedback.

Make sure your demo is practiced for timing, brief and to the point, and demo with a sense of haste. This will help ensure you are leaving room for feedback.

No demo due to lack of UI

The team doesn’t have a UI, or UI work to demo, so they think Sprint Reviews aren’t applicable.

Remember that the team is demonstrating completed work, it doesn’t to have a UI. They might be demonstrating header and body of an API request and/or response; or running a command from the cmd line and looking at the response. That’s okay!

Context of the work is missing

A stakeholder might be confused to the context of what you are demoing and lose interest.

It’s always a good idea to start the Sprint Review with context of the work in the big picture; perhaps in a roadmap, or where it fits in an epic, or where it fits in with a release schedule. Don’t be afraid to provide context while demoing as well.

Unpreparedness, awkward pauses or gaps

The team starts late, or forces stakeholders to awkwardly wait while fumbling through technical detail or setup, or the handoffs are uncoordinated or simply lack flow.

Practice! At least one test run will go a long way in making the team talk through content, handoffs and overall time of the Sprint Review.

Progress and achievements aren’t celebrated

The Sprint Review feels like a death march, lacks energy and appreciation.

The Sprint Review should also be a celebration of the work achievements. Stakeholders should be reminded of this, you can do so with commentary in the presentation slides, and asking for a round of applause at the end of the meeting.

Focus on documentation over working software

The team is demoing documentation.

Stakeholders don’t need a meeting to watch you read docs. Ensure the focus is on demoing working software.

Overly long and unfocused feedback discussions

Feedback sessions get into the weeds and turn more towards technical design and/or planning.

The entire audience has no interest in hearing feedback being resolved during the meeting. The Sprint Review facilitator must carefully guide these conversations and interject if they get to far into the weeds, suggesting that there be a follow up meeting to hash out further details.

Team is resistant to feedback

The team hears feedback but is consistently resistant to it.

It’s important to remember that the stakeholder is your customer. If the team is resistant to their feedback, the stakeholders will be disenchanted and might stop attending. It’s important to hear and repeat the feedback, and if there is a disagreement have it taken offline for further discussion and better alignment.

In Summary

Addressing the pervasive issue of low attendance at Sprint Reviews is crucial for the success and morale of our teams. As I’ve written, there are a lot of things that can impact the perception, attendance and ultimately success of your Sprint Review. Spending time thinking about the audience perspective and tweaking your practice and techniques will go a long way in increasing your Sprint Review attendance. Establishing a solid Sprint Review is an adventure; don’t forget to solicit feedback, iterate and experiment to improve over time!

Have you experienced other killers? Share it in the comments!

Subscribe now

Today I reviewed and want to share with you the findings of the working paper entitled “The Power of Proximity to Coworkers: Training for Tomorrow or Productivity Today?” This paper was written by Natalia Emanuel, Emma Harrington and Amanda Pallais and is supported by the National Bureau of Economic Research.

The paper explores the effects of proximity to coworkers by studying software engineers at a fortune 500 company, whose main campus has two buildings several blocks apart. This distance between the buildings closely simulates a work from home (WFH) environment. In early 2020, the buildings were then closed for COVID-19 and the research continued.

The summary of the finding is:

Remote work leads to a tradeoff - It increases output today, particularly from more senior workers. But remote work decreases training of more junior workers, which has future costs. Work arrangements seem to respond to this tradeoff with junior workers and potential mentors less likely to work remotely.

Seems logical and is likely something you’ve experienced right? The devil is in the details though, below I’ve extracted 6 impactful findings.

6 findings in the study

1. Sitting together reduces senior engineers' programming output by 39%, due to mentoring of junior engineers. When not in proximity the gap closed.

2. Engineers working in the same proximity as their teammates received 22% more online comments on their code than engineers with distant teammates. However after COVID-19 this advantage disappeared.

3. Sitting near coworkers increases online feedback on their code; engineers ask more followup questions online when sitting together, and so proximity can increase in-person AND digital communication.

4. Female engineers who were in the same proximity as all their teammates received 40% more feedback than female engineers with distant teammates. However with COVID-19 office closures, there was a differential decline of 21%. Largely driven by follow-up questions and clarifications, suggesting that women feel more comfortable asking for additional feedback in-person.

5. Proximity impacts career outcomes. Junior workers in proximity with their team are 5% less likely to receive a pay raise, consistent with their lower output. However, once the offices closed, and the mentorship equalizes, the engineers benefit from the mentorship that they have received and are 7% more likely to receive a pay raise.

6. Adding a new hire, not in proximity, reduces feedback among proximate teammates (who predate the new hire), while adding a new hire in the same building has no such impact. Teams’ attempts to accommodate distant teammates by, for example, moving in-person meetings online, have substantial negative externalities.

How to reduce the productivity impact

Based on the working paper, I recommend the following to engineers to remove friction and increase productivity when working within a remote team:

• When growing your team, you can avoid short term productivity loss by hiring senior engineers OR hire junior engineers when you can afford the short term productivity loss.

• If you hire a junior person, work quickly to train and mentor them, this expedites their learning and increases chance to get a pay raise.

• Formally train your new hire on their missing skills immediately, letting it naturally happen on the job will take far longer at the expense of your senior engineers.

• If you’re a junior engineer WFH, don’t be afraid to ask follow up questions.

• If you’re the single remote worker on the team, work hard to remove friction such as time zone differences, start and stop times, your status/whereabouts and response time latency.

• Make sure to be giving feedback (Slack, code reviews, etc.) to co-workers when WFH, make no assumption that it’s not needed.

• Coordinate the days your teams spends in the office to increase mentorship opportunities.

• Create a permanent online team room, with video on, where team members can work in the presence of others, ask questions and learn by overhearing.

In Conclusion

The working paper explored how software engineers work when in proximity of each other in the context of one building, two buildings and WFH. As teams continue to adapt to evolving work arrangements, when it comes to productivity, it’s important to remember that there must be a balance between immediate productivity gains and the long-term development of human capital in a remote work environment.

I found that this study confirms many of the things that we know when teammates are not working in proximity, but have a hard time articulating. Prior to reading this study I assumed that a two building teams’ work behaviors would be congruent with WFH. Given the difference of variables though, it’s just not that simple.

In reflection of engineers interacting less when WFH, I’m left wondering how much the societal changes that came with COVID-19 have caused some of the behaviors described in this paper -- knowing that COVID caused an accelerated digital transformation, flexible work arrangements, a change to our values and priorities, and a focus on mental health.

What are your thoughts and experiences?

Share Engineering Markdown

Hiring developers in lower-wage countries to decrease labor costs.

Now that COVID has ushered in a consistent WFH culture, our workplace is quickly becoming more geographically distributed, further opening up the opportunity to hire in lower-wage countries (LWC). From my experience, the desire to hire in LWC usually originates from executives’ desire to lower labor expenses, especially when the market conditions are poor and impacting the bottom line. This seems logical right? Perhaps, but there is a hidden cost that can destroy that labor savings, if not done thoughtfully. That hidden cost is slower software delivery.

You might want to hire in low-wage countries to lower your labor costs, but you may be putting at risk team productivity, thus resulting in slower software delivery.

Factors that slow down software delivery

Let’s face it there are a LOT of things that can impact team productivity and on-time software delivery. Let’s step back for a second and look at the research on Factors Affecting On-Time Delivery in Large-Scale Agile Software Development. When you have some time, read through it, it’s pretty satisfying to see data that is historically pretty hard to quantify. To keep things moving here, I’ve highlighted the top 5 factors that affect delivery from a table in the research findings:

To simplify, the top 5 factors that cause software delivery delays are:

1. Requirements refinement

2. Task dependencies

3. Organizational alignment

4. Organizational politics

5. Geographic distribution of teams

Note that Geographic distribution of teams comes in at #5, which certainly isn’t helping to justify saving money by hiring in a LWC. But why?

An example of time zone differences

Considering that data, let’s get back the topic of extending your U.S. based team to include LWC. These days, LWC that have tech talent available to the U.S. are primarily in EMEA and South America. The problem is that iff your existing team is located in the United States, there can be a significant difference between these two time zones.

The geographic distribution coupled with large time zone difference is where things start to get messy for a team.

To help illustrate time zone difference impact, let’s define a hypothetical team situation:

• A team in Texas works from 9 AM - 5 PM.

• The team in Texas (UTC-6) wants to hire a software developer in Ukraine (UTC+2) due it being a LWC.

• Texas is 8 hours behind Ukraine. If the Texas team starts the day with a standup at 9 AM, it is 5 PM in Ukraine.

In this extreme but realistic example, the glaring problem is that Ukraine’s 9-5 workday is ending when Texas’ begins; there is no overlap in their workday to spend time together as a team.

Time zone differences can cripple teams

As you see in the Texas and Ukraine example, when you have large time zone differences, you have a reduction in overlapping working hours between the individuals in the two countries. When this occurs the team has to start dealing with burdens such as:

• Lack of overlapping meeting availability.

• Delayed decision making.

• Delayed task dependency resolution.

• Work-life balance concerns, due to nontypical workday schedules.

• Risk of isolation for the non-US employee.

• Reduced team cohesion.

These burdens WILL impact speed and efficiency of what a team can deliver. If you spend a hot minute thinking about the the above burdens coupled with with the top 5 factors for delay, you can start to see that a lack of overlapping time between the team members is going to introduce serious time delays. A simple example being that you have a question and then having to wait until the next day to get that answer. Over and over and over; these delays add up.

When are time zone differences tolerable?

Is there a way to utilize LWC and organize the team so that team productivity is tolerable? Perhaps, a few conditions to consider are:

• When the whole team works in the low-cost region.

• When there is an 3+ hour overlap of working hours between the regions.

• When the people in the low-cost region work during U.S. hours.

• When the work has very little dependency on the U.S. team.

• When the person in the low-cost region have senior experience.

• When deadlines are less important.

Things to consider before hiring in a LWC

If you have to hire in a LWC, here are a few things you can do to minimize the impact:

• Target countries that have at least a natural 3 hour overlap with the team’s workday, that way you have ~1/2 the day for meetings and collaboration.

• Put the desired team time overlap (e.g. 3 hours; 9AM-12PM) in the job posting. Being explicit upfront will set expectations right out of the gate.

• Ensure your product, epic, story requirements are always detailed and documented. This prevents less back and forth.

• Visualize all of the work the team is doing (planned and unplanned). This ensures that everybody knows about ALL the work being done by the team and will reduce confusion and back-and-forth conversations.

• Have the team update story and task status at the end of each day. This paper trail is invaluable to those trying to understand the state of the story/task when teammates aren’t available.

• Publish a list of blockers/dependencies/ needs at the end of each workday. This list is something the “next shift” can focus on clearing to keep the whole team productive.

• Ensure that the team is discussing and breaking down the work in the planning meetings. This collaboration will shake out questions and thoughts right away instead of surfacing later, and then having to wait on an answer.

• Ensure the team is doing retrospectives, minimum bi-weekly, and talking about how they can improve delays/wait-times.

In conclusion

Hiring developers in lower-wage countries (LWC) can be an appealing cost-saving strategy, but it comes with potential pitfalls that must be navigated thoughtfully.

Time zone challenges quickly expose the top 5 factors that cause software delivery delays. However you can proactively mitigate these factors by targeting countries with a reasonable time zone overlap with the rest of the team, and being explicit about workday collaboration time. Doing so can mitigate the impact of meeting availability, decision-making, task resolution, work-life balance, team cohesion, and overall efficiency.

Leave a comment

Now that I’m committed to writing here on Substack, it’s time to set a goal with measurable results for myself. I’ll use the goal setting methodology OKR for that (Objective, Key Result). Here is what I came up with:

Objective: Spread/scale my wisdom of engineering, leadership and human experience.
Key Result: A newsletter brand is created on Substack.
Key Result: A newsletter is published once a week.
Key Result: Newsletter subscriptions have reached 10,000 by end of Q2 2024.

To keep myself on track, I’ll use a KPI (Key Progress Indicator) to monitor the progress of our OKR; my KPI is simply a metric that I can monitor in near-realtime. At a minimum, I’ll review my progress with the KPI on a weekly basis and make any adjustments to my work to keep the OKR on track.

Since I want to spread my wisdom by achieving 10,000 subscribers (inherently scaling), it’s logical that I would use Substack’s subscriber count as my KPI. Let’s take a look… Here is my baseline KPI: 2 subscribers as of Jan 8, 2024:

A bit of history on this chart: The first subscriber is me, when I was exploring Substack last year, and the 2nd is a peer that has recently been coaching and motivating me to write.

OH… and-look-at-that… I’ve procrastinated for 14 months since I first engaged with Substack 🫠. Alright, it was’t complete procrastination, I did explore what a newsletter might look like on LinkedIn for a while with for the Love of Software.

Well, I’ve got wisdom to spread, writing to do, and an OKR to achieve. Wish me luck! Better yet, send a few people my way that you think might be interested in what I have to say about engineering, leadership and the human experience.

Share Engineering Markdown