Technical User Story writing

I am not sure how to phrase these things in writing. Please help.

Scrum does not mandate the use of user stories and therefore user stories should not become a crutch to adding / creating Product Backlog Items. The purpose of user stories was to generate a discussion / conversation around what functionality needs to be implemented.

Consider using the FDD syntax for capturing Product Backlog Items.

See this article by Mike Cohn.

https://www.mountaingoatsoftware.com/blog/not-everything-needs-to-be-a-user-story-using-fdd-features

Hope this helps.

Technical User Story writing

I am unable to coach him because I am struggling myself.

I imagine I'd struggle with that too. My advice is to dispense with the idea of even having a "technical user story".

If the business value of the table you refer to is not clear, perhaps it simply needs to be articulated as a technical item on the Product Backlog.

As long as the PO can understand and order this item in relation to other work on the backlog, there need not be a problem. The Development Team may provide advice on this refinement.

A User Story is used to convey the needs of an user.  However, a user does not have to be an actual person.  A user of a REST service is going to be another application.  So don't try to write user stories differently based on the work. Define the user needs that you are trying to satisfy.  

In your example, there is nothing different that should be done based on the requirement.  What is the problem that you are trying to address by having the Development Team do work?  That is what you describe in the user story.  The statement that a table be created first has nothing to do with the intent of the user story.  It is just a detail that needs to be taken into consideration while work is being undertaken.  Honestly, I'd include that requirement as a comment because it is a technical detail and coming from the Product Owner it is more of a suggestion than a requirement. In the end, it is up to the Development Team to decide the technical implementation and they may feel that there are other things that need to be done before the table is created.

Hi Daniel, 

a couple of questions as a follow-up to your answer.

1. Are the "details" or "technical implementation" figured out during Sprint execution or before it?

2. What if the "technical implementation" we choose now will force us to do rework 3 months down the line as we are focusing only on the US rather than the Product roadmap when designing the solution. How do you tackle this?

3. Where do the software/system/solution Architects come into picture?

1. As with any change to a product in an agile organization, the details/technical implementation will evolve as work is needed.  I'm going to turn this back on you and ask how much of the details/technical implementation is needed in order to make the Product Backlog Item ready to be pulled into a Sprint? How much can be created as the work is done?

2. So what?  That is the great thing about being agile.  You can adapt to change when it is needed.  What if you tried to make the work functional for other countries but the product is never made available in any country but the US?  That seems like wasted work.  But IF YOU KNOW that the product is going to be made available in other countries, there should be something in the Product Backlog Item stating it as a need.  Or another Product Backlog Item to introduce multi-country capability.  There is nothing to say that rework 3 months from now will be required, even if you try to plan ahead for what is known to be needed in 3 months.  A lot can happen in today's environments in 3 months.  Build for today and adapt for the future. 

3. The Scrum Guide defines Developers as 

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

The specific skills needed by the Developers are often broad and will vary with the domain of work. 

Would you say that software/system/solution Architects reflect those statements?  If there is a need for their skills to complete product changes, then they would be part a Developer. If there is not a constant need for their skills, they could be used as advisors for the Developers. Most often I see these people working as advisors for the Developers across multiple Scrum Teams to help create organizational standards.  There is nothing in the Scrum framework that goes against this model.  The architects just become part of the process that Scrum Developers adopt in determining the technical implementations for their work.  Scrum Teams should use any information sources that they can in making decisions.