305: Maximizing Business Value with User Stories

Capturing a behavior change makes a story measurable from a business perspective

Thank you for reading Snippets of Text. Snippets from media about tech, programming, parenting, and more. This is a preview of a post available exclusively to paying subscribers. You can get unlimited access to all articles by purchasing a subscription.

Thank you for checking out the free preview of Snippets of Text. Please consider subscribing to the paid version if you find my work helpful. This will allow me to dedicate more time to developing new ideas to share with you.

Off Topic: Strategies for Guiding Technical Direction

As a staff engineer, your role encompasses more than just technical knowledge. You must also possess strong communication and interpersonal skills to build and maintain relationships with stakeholders, team members, and other departments. Additionally, you are responsible for guiding and directing your team members through evaluating various technologies, tools, and techniques. You can deliver high-quality software and develop successful cross-functional projects by researching and recommending the best solutions.

You must prioritize your organization's and stakeholders' needs to set technical direction. This process ensures that all decision-makers are on board with taking the first step towards change. To achieve this, you must understand what they want from the change and how they will feel when they get there. Investing in the development of engineers through mentorship and guidance can significantly impact a company's long-term success. Having increased administrative authority provides new tools for solving problems. Retaining an executive officer in a well-managed organization requires nuance and restraint. Identify the problem, potential solutions, and the steps to fulfill them.

To become a staff engineer, you must deeply understand technology and architecture. It's also essential to develop pragmatism and remain skeptical of yourself. With this approach, your engineering strategy will be more accurate. Having practical visions that serve both your users and your business is crucial. While being ambitious, your visions should be moderate and specific. This approach makes them more helpful and meaningful when resolving conflicting strategies. To create an engineering vision, list five strategies and predict their outcomes two years later.

Being a staff engineer is more than just a job title. Your actions and influence within the organization determine how your contributions are acknowledged. As a senior staff member, your primary responsibility is to the company and its needs rather than your own. Moving into a staff-plus role means taking on leadership responsibilities, which means the resources and support you relied on before may be limited. To excel in this role, it's essential to understand how to work within the organization's hierarchy and maintain alignment with its goals. Staff engineers are expected to guide their team's technical direction.

Being a staff engineer requires intention and purpose rather than just a busy schedule. To make an impact, you must ensure that every step aligns with your goals. Doing so can influence leaders within your organization and achieve meaningful progress. Support other leaders striving for progress and provide constructive feedback that doesn't hinder their efforts.

Even accomplished principal engineers can experience impostor syndrome. Remember that staff engineering is not just a role but the intersection of the role, your behaviors, your impact, and the organization's recognition. In senior positions, you're accountable to the business and organization first and yourself second.

Staff-plus roles are leadership roles, and the support system that got you here will fade away. To remain effective within a staff-plus role, you must learn to stay aligned with the organization's authority. Staff engineers are expected to define the technical direction of the team they are operating in. To assist senior engineers, managers must offer feedback that helps their progress. Exemplary engineers can influence the code we produce, the algorithms we put in place, and our choices.

Current Work: Maximizing Business Value with User Stories

Businesses place great value on stories because they provide a vertical slice through the layers of the system and help teams focus on product behavior rather than its construction. Some teams use informal scales such as high/medium/low or a ten-point scale to quantify business value. User stories should be independent to allow implementation in any order. While they should be concrete enough for developers to estimate, they should contain only some implementation details. The specifics can be negotiated between developers and the business. 

A user story should have clear and quantifiable value to the company and should not be larger than what one or two developers can implement in a single iteration. The number of stories per iteration should match the number of developers on the team. Valuable but inexpensive stories should be done immediately, while valuable but expensive ones should be done later. Affordable but valuable stories may be completed eventually, and costly but non-valuable stories will never be done. 

The best predictor of iteration progress is the previous iteration. The project is ongoing until all the stories are implemented, and it's over when there are no more stories in the deck worth implementing. User stories encourage sharing the model of how users think about the system, allowing teams to consider product use rather than construction. Debating and analyzing ideas becomes easier when expected behavior is defined in a shareable form. Refactoring, architecture, and code cleanup are not stories.

I invite you to upgrade to a paid subscription. Paid subscribers have told me they have appreciated my thoughts & ideas in the past & would like to see more of them in the future.