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]

17 Responses to “Technical User Stories – 3 Reasons NOT to Have Them”

  1. Andrej
    January 31, 2011 at 8:28 am #

    Tech stories are boring and don’t bring any commonly understood value

  2. Pichat
    January 31, 2011 at 7:06 pm #

    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

    • peter
      January 31, 2011 at 10:06 pm #

      Thanks for the note. The backlog should be a centralized ‘talk center’ where information is communicated and disseminated. Well said.

    • wouter dewanckel
      February 3, 2011 at 2:21 am #

      Totally agree.
      Did one guy once -I thought he was called Jeff or something ;-) – not state: If it is not on the backlog, it doesn’t exist?

      • peter
        February 3, 2011 at 8:48 am #

        Yes…. interesting….

      • Pichat
        February 5, 2011 at 11:32 am #

        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!

        • peter
          February 5, 2011 at 1:50 pm #

          Great insight here. There is more to the full completion of a story than just technical things. Non-functional aspects as well!

  3. Krish
    April 26, 2011 at 12:00 pm #

    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?

    • peter
      April 26, 2011 at 1:24 pm #

      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.

  4. Craig
    August 29, 2011 at 7:36 am #

    Thanks for sharing :)

    Shall be nicking this insight.

    • peter
      August 29, 2011 at 9:51 am #

      Sweet ! Glad I could help!

  5. Dave Babicz
    September 1, 2011 at 11:08 am #

    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…

    • peter
      September 1, 2011 at 11:10 am #

      Would love to see it! Link your post here after you’re done!

  6. rashmi
    March 5, 2013 at 12:32 pm #

    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.

Trackbacks/Pingbacks

  1. Tweets that mention Technical User Stories – 3 Reasons NOT to Have Them | Agile Scout -- Topsy.com - January 31, 2011

    [...] This post was mentioned on Twitter by Rafael Viveiros, Agile Scout and Dorin Lupu, Agile Scout. Agile Scout said: Technical User Stories – 3 Reasons NOT to Have Them http://goo.gl/fb/r91n5 #agile #pmot [...]

  2. Technical userstories: pick a side » Agile Things - September 18, 2012

    [...] More about his reasons on his blog [...]

Leave a Reply