I currently work on a large scale software project in a large company.

We follow an agile approach for development; however, due to the size of the the company there are several stakeholders that normally are not spoken about or simply assumed to be the developers in the Agile process.

Stakeholders example:

  • Architecture: Defines enterprise architecture guidelines

  • Development: Defines enterprise development guidelines

  • Product Design: Defines enterprise branding and design guidelines

  • IT Security: defines enterprise IT security guidelines

  • Operations: 24/7h operations support

  • Customer Support: 24/7h client support

  • Rollout: Rollout of the application per client ( client specific configurations )

Should I use User stories?

  • As IT security, I want to ...

    or Debt tasks?

  • Tech debt - Code needs to be refractored

  • ISO debt - Application must follow ISO1234

  • Rollout debt - Configuration automation

  • Operations debt - Special tool to manage data cache

Pratical example:

  • As application management, I want to be able to invalidate the cache, so the application is cleared of corrupt data.

The above doesn't really make sense to me as a business value user story. It represents more a maintenance required feature.

  • Is there any common practice on how to integrate the requirements of these stakeholders in user stories?

  • What is the best way to express the requirements from these stakeholders? They are functional yet not business value adding requirements.

  • 1
    Hi evilloop. The title of your question didn't match the body, so I made some edits to help unify the two. I also moved the questions to the bottom where they're visible so people answering don't miss one. This helps ensure we are voting on answers using equivalent criteria, so we can vote the best to the top. Take the tour to learn more of how our site works. Hope this helps.
    – jmort253
    Jun 21, 2015 at 10:16
  • Closely related: pm.stackexchange.com/a/10799/4271
    – Todd A. Jacobs
    Jun 21, 2015 at 13:29
  • Thanks for the link, it was clarifying. I think that at the end of the day, most of these " non-user" user stories, map tos ways of managing the debt created by a business user story.
    – eviloop
    Jun 21, 2015 at 16:53
  • To add value we have to create waste. user stories are born to manage this waste. For example: A user story to build a tool to manage the caching system implemented in a business feature
    – eviloop
    Jun 21, 2015 at 17:01
  • also related: pm.stackexchange.com/q/14189/17552
    – eviloop
    Jun 21, 2015 at 18:06

2 Answers 2


User stories are about delivering business value to end users of the software. Generally user stories are the responsibility of the Product Owner and the business stakeholders.

Now how those user stories get delivered is down to the development team. They will typically have a defintion of done that covers what they regard as the important elements of delivery. That definition of done could well include ISO compliance, security, architecture and many other items on your lists.

It isn't necessary nor desirable to seperate the technical and non-functional requirements from the business requirements. Better for the team to concentrate on satisfying business requirements but do the technical and non-functional parts as an inherent part of the way they work.

As an example, a team I am working with now have a business user story that requires them to modify some database code that hasn't been worked on in a while. As a part of the business story they are going to refactor some SQL. That means the business story will take a longer than if they had not done the refactoring. But the team's approach is to deliver software that meets their coding standards and agreed good practices.

I'm not a big fan of seperating out the technical from the business stories. It is more difficult for business users to evaluate progress as they don't always understand technical stories. It also runs the risk of technical tasks continually contending with business functionality. Better to simply define your team's definition of done while working on business focused stories.

  • 2
    Shouldn't technical stories just go on the Sprint backlog, since the development team owns that artifact, and since technical debt and technical details are the responsibility of the team?
    – jmort253
    Jun 22, 2015 at 7:28
  • 1
    Sure, you can add technical stories to the sprint backlog. But an alternative approach is to add technical work as sub-tasks of business value stories. Try and avoid driving a wedge between business functionality and the technical requirements needed to achieve them. Jun 22, 2015 at 11:50
  • thanks for the response ! I see your point. How about create them as sub-tasks first and move them to the sprint backlog as tech stories if the debt is accepted by the team? due to an unforeseen delay for example.
    – eviloop
    Jun 23, 2015 at 16:37
  • 1
    The problem with moving the tech debt to the backlog is it hides the true cost of completing a business story. Say we spent 2 days completing a business story but moved several days of tech debt to the backlog. The business thinks it is getting the story done for 2 days worth of effort, when really the true effort is considerably more. Jun 23, 2015 at 18:37
  • 1
    The problem with moving it to the product backlog is then the business operations, who may not understand the impact of technical debt, may prioritize something at the bottom of the product backlog that is the responsibility of the technical team. That's why I was suggesting it should go on the Sprint backlog since it's the team's responsibility to manage. However, I am not sure how to solve the problem of not making it clear to management that more effort is required. The best solution is to have clear definition of done criteria to where you just don't allow tech debt in the first place.
    – jmort253
    Jun 24, 2015 at 7:36

Ongoing quality and technical criteria should be covered in the teams 'definition of done', rather than a separate piece of work. This may improve with time, for example at first there may be limited security criteria, however 6 months later it might be decided that all work must meet standard PQR4567 before it is considered done.

If you separate architecture, refactoring and technical debt into technical stories, they will always be prioritised below a new feature. "Refactor the dinglebat" will always be lower priority than "Add a new doodlebot" to a business owner, and will always be bumped down the backlog. If it is something technical but totally new, it is valid to be prioritised by the business owner as a feature. For example, initially deciding we want to be PQR4567 compliant is adding business value, so that makes a valid story. Once it is completed, it is added into the definition of done to ensure the compliance remains.

When it comes to "Adding a new doodlebot", the team should have the freedom and transparency to explain that in order to complete this they need to refactor the dinglebat, so it will take this much time. The business owner can't push back on how the team do things, but if this is totally unacceptable they could look at how else they could achieve the objective. One of the key tenets of agile is not compromising on quality, otherwise you end up with a slowly degrading product and a pile of technical debt that becomes too big to tackle.

  • You are totally correct. I have seen this happen several times. It is indeed better to keep them as a part of Done or as a sub tasks like suggested by Barnaby Golden above.
    – eviloop
    Jun 23, 2015 at 16:39
  • +1 i liked your answer, but the other one got more votes so i will mark it as accepted, sorry
    – eviloop
    Jun 23, 2015 at 17:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.