Agile in enterprise: How to represent the requirements of non-business stakeholders?

Question

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.

Answer 1

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.

Answer 2

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.