Suppose, Team Alpha in Jarotball (Company Name) has encountered the need for "technical" user stories (TUS). Among the following options, who do you think would decide the priority of TUS?

• [ ] the Product Owner with help from Operations
• [ ] the Tech Lead with help from the Product Owner
• [x] the Product Owner with help from the Tech Lead
• [ ] the Tech Lead with help from Operations

1. What is Technical User Stories?

• A Technical User Story is one focused on non-functional support of a system. For example, implementing back-end tables to support a new function, or extending an existing service layer. Sometimes they are focused on classic non-functional stories, for example: security, performance, or scalability related
• Dont overload the functional user story!!!.

• Scenario 01:

  • if there were a User Story to allow for logon and authentication of a user to a web based Credit Union application.
  • Suppose there was no infrastructure for web-based authentication within the Credit Union customer infrastructure.
  • It exists for the kiosk-based ATM’s, but would be a new function for the web app.
  • To me this would expose infrastructure that is required to support the base functionality for the Login story.

• Solution 01: A Bad approach (it overloads the functional user story)

  • One-way to approach this would be to build this as a function, requirement or dependency within the base story.
  • While that would work, it’s really not part of the function and we’re overloading the story.
  • How to write this
    • As a user requesting authentication,
    • I need to be able to login via the web app,
    • so that I can manage my account details via the web
  • While this does define the functionality, it doesn’t address underlying infrastructure.

• Solution 02: A better approach (introduce it in technical user story)

  • In clear English the story might look like:

    We need to extend the kiosk authentication code in our security services layer to include a new authentication mechanism for web-based (browser) applications. It needs to include 2-layer authentication: passwords and user-centric questions.

  • Let's write it:
    • Verify that all web-based requests get thru the service layers and receive a reply within 2 seconds
    • Verify that HTTP, Radius SecureID, and LDAP authentication protocols are supported
    • Verify that the authentication timeout performs at 25 seconds
    • Verify that 2-phase questions (3 in total) are presented every 3-5 login attempts
    • Verify that 2-phase questions are applied after a 3x password entry failure
    • Verify that password entry retry limit is set at 5x

      I hope you can see how useful the acceptance tests are for this technical story. I hope this example at least gives you an idea of the distinction between the two types.

1.1 Types of Technical User Stories

• Product Infrastructure – stories that directly support requested functional stories. This could include new and/or modified infrastructure. It might also identify refactoring opportunities, but driven from the functional need.
• Team Infrastructure – stories that support the team and their ability to deliver software. Often these surround tooling, testing, metrics, design, and planning. It could imply the team “creating” something or “buying and installing” something.
• Refactoring – these are stories that identify areas that are refactoring candidates. Not only code needs refactoring, but also it can often include designs, automation, tooling, and any process documentation.
• Bug Fixing – either clusters or packages of bugs that increase repair time or reduce aggregate of testing time. So this is more of an efficiency play.
• Spikes – research stories that will result in learning, architecture & design, prototypes, and ultimately a set of stories and execution strategy that will meet the functional goal of the spike. Spikes need to err on the side of prototype code over documentation as well, although I don’t think you have to “demo” every spike.

1.2 DO YOU DEMO TECHNICAL USER STORIES?

I can’t tell you how often I get “pushback” from my students and coached teams surrounding this point. Usually teams don’t want to demo the Technical User Stories. The rational (excuses) normally fall into the following areas:

There is no UI so we can’t demo it;

• They (the stakeholders) only care about the functional software.
• They don’t care about infrastructure or Technical User Stories;
• It’s going to be a very odd demo to show this behavior off IF we don’t have the supporting functional software completed at the same time;
• It’s not going to be worth the effort to demonstrate our meeting non-functional requirements (acceptance) for the story.

  While I clearly acknowledge that it’s often harder to demonstrate Technical User Stories, I think the payback is worth the investment and effort.

1.3 Illustrating Agile User Stories Creation and Acceptance Criterion

1.3.1 How to write an Agile User Story

1.3.2 Agile user story acceptance criterion

2. Product Owner - serves as the customer proxy to Agile Team

Lets start with an Agile Manifesto

Business people and developers must work together daily throughout the project.

• The Product Owner (PO) is a member of the Agile Team responsible for
  • serves as the customer proxy responsible for working with Product Management (PM) and other stakeholders
  • defining Stories and prioritizing the Team Backlog to streamline the execution of program priorities
  • while maintaining the conceptual and technical integrity of the Features or components for the team.
• The PO has a significant role
  • in maximizing the value produced by the team and
  • ensuring Stories meet the user’s needs and
  • comply with the Definition of Done.

2.1 Relationship between Product Manager(PM), Product Owner(PO) and Agile Team

Each Product Manager can usually support up to four POs, each of whom can be responsible for the backlog of one or two Agile teams.

3. Tech Lead

• Agile Tech Leads Wear Many Hats in Different Organizations.
• For example, tech leads are assumed to be mentoring the team on completing their assignments, and they are the first to respond to technical blocks raised by the teamFor example, tech leads are assumed to be mentoring the team on completing their assignments, and they are the first to respond to technical blocks raised by the team
• A Tech Lead or Technical Lead is a software engineer who also leads a small programming team. Tech Lead should be able to:
  • Work closely with product managers and story owners to design features and prioritize tasks.
  • Support teams by answering questions and solving problems.
  • Assemble releases and drive improvements in release processes.
  • Help with recruiting and hiring.
  • And – write code.

3.1 Can engineers manage?

Tech Lead is a tough job, and some say that engineers can’t do it. You might have heard people say “a good engineer is a bad manager.” I don’t believe it. There was a time when people said that engineers made bad entrepreneurs. Today, software engineers run the most successful technology companies, and the hottest startups.

4. Solving Question through Elimination Strategy

• [ ] the Product Owner with help from Operations .[S01: No, though PO will prioritize TUS, but its not with operations]
• [ ] the Tech Lead with help from the Product Owner [S02: Its mainly the PO jobs to prioritize the TUS ]
• [ ] the Product Owner with help from the Tech Lead [S03: Probable solution as PO prioritize with the help from Tech Lead]
• [ ] the Tech Lead with help from Operations [S04: Its the PO focused job, not the Tech Lead focused job ]

4.1 Answer

Suppose, Team Alpha in Jarotball (Company Name) has encountered the need for "technical" user stories. Among the following options, who do you think would decide the priority of these?

• [x] the Product Owner with help from the Tech Lead [S03: Probable solution as PO prioritize with the help from Tech Lead]

Final Thought

To conclude, I would say, The PO has a significant role in maximizing the value produced by the team and ensuring Stories meet the user’s needs while comply with the Definition of Done.