Technical User Stories – 3 Reasons NOT to Have Them

Ron Jeffries is well known. He’s so well known that he doesn’t even have to tell you who he is. You should just know. A quick trip to his Twitter page tells you that. #ronjeffries #pwnd

Regardless, we always perk up whenever we read something he has to say. Usually it’s pretty interesting stuff. His latest blog entry tells us that we do not need technical user stories. Period.

Why is that?

Let’s break it down for the rest of us peons, shall we?

“One of the pillars of Scrum is for the Product Owner (PO) to prioritize work for the team, so that the best possible product can be delivered within the desired time and budget. Clearly, the PO is (should be) capable of pinpointing the most value. Therefore, it isn’t too smart for a development team to focus on anything other than what the PO wants.”

Since technical user stories have the promise of providing faster velocity in the future, and are different from the PO’s user stories, you end up having a priority and time dilemma: PO user stories VS. Technical user stories.

Ron Jeffries 3 Reasons to NOT Have Technical User Stories

  1. PO stories should inherently be built with a creation of tests and a creation of clean code from the beginning.
  2. Since systems are built incrementally, the design should be built incrementally as well. In order for each feature to be really “done” design must be done with development.
  3. The PO has no real ability to prioritize technical stories, and shouldn’t have to. They prioritize the standard stories.

Bottom line? The PO should only prioritize the regular user stories. A development team should bake in the time it takes to correctly code and design the story. It may take longer per story (slower velocity), but that’s ok.

“Our Product Owner retains her ability to prioritize the whole of our work, and our code improves. No confusion, no political discussion, no need to make promises about the future that we may not be able to keep.

We don’t need technical stories or tricky negotiations. We just do the job we were always supposed to do, namely make each story DONE, fully tested, with a good design in place.” – Ron Jeffries

Thoughts on this? Let us know in the comments.

[HT: XProgramming]

19 Replies to “Technical User Stories – 3 Reasons NOT to Have Them”

  1. Technical debt, non functional requirements and ideas from the other talents in the team… how do you handle these?

    Focusing on perceived value of only one team member sounds for me like a classical organisational trap: looking too much on one aspect of the development process and not making use of crossfunctional teams. As a result you’ll get strong (product) managers and weak engineering. One of the agile principle is that business people and developers must work together daily throughout the project. Perhaps I am wrong, but I see the backlog as a central communication tool, as a chance to balance information flow and influences on the development process. I am sorry if this means that a product owner has to speak with developers about technical implications from time to time. 😉

    Greetings from a agilist with the sniffles

      1. Thanks for the quote!

        One additional thought, if we don’t visualise all our process activities and possible wastes, we will not be able to improve them. One guy once – I thought he was called Jeff too – called them impediments. I met a Scrum team at a client last week and they added “Verfied by QA team” to their definition of done… first I was surprised that they added an external dependency and the Scrum master explained their motivations. Verification was for months a bottleneck in the overall process flow and could be easily demonstrated to the PO by just standing in front of the kanban board. It became crystal clear that improving stakeholder cooperation in this case would lead to a faster development cycle, faster response time to emerging requirements in the product backlog, therefore better value to our end customers.

        Customer value is not only about features and user stories, improving non-functional aspects of process activities are equally important to products and the organisation that creates them.

        Have a good weekend!

    1. Preach brother Preach!!!!!!

      Collaborate Together. Learn Together & Grow Together…

      This is agile development where no one can ever live in a world of absolutes..

  2. What if team has few technical stories. I know it’s cultural shift for team to NOT to focus on technical stories. How do I make this happen? Do you assign a story point to these Tech Stories? How do they impact velocity?

    1. In my opinion. This approach may be to dogmatic. Technical stories may still have their place with the rest of the stories. Estimate them appropriately and so forth.

  3. Thanks for the post. Incites me to write my own take on this in my blog and how I coach teams to use technical user stories…if I coach them that way. Coming shortly…

  4. Dear writer,

    I am new to agile process. First time i am using agile in my project. Client manager asked me to write technical user stories. Could you please guide me how to write tech stories. What should be perspective, functional or technical? What should be various column headings and content for ui based and background process like batch job???

    From given blog i could understand tht tech in agile work must start with business stories. But why we should not create tech stories, this is not clear.
    Thanks in advance.

  5. Hi,

    Has anyone written technical userstories for transferring data functionality between Test, Prod and other environments for other teams to access the same data?

    If so please can you let me know how to go about that.



Leave a Reply