Does it make sense to require developers to write a "business value add" section in each issue?

Question

Background

In our company we demand that engineers write a brief one liner section in each ticket they work on (from jira/github/gitlab etc) that explains the "business requirement".. the logic of that is explained here (text copied from our "issue protocol" document verbatim):

Business Value add

The software projects we work on must always ultimately serve a business need. Simply put b/c at the end of the day, someone should be paying for the development of these tasks. Therefore, it's very important to express the value add of the task in a language that non-technical person can understand and appreciate.

Think about it in the following scenario: we bill the client per issue (ie in the monthly invoice we add the issue number and description in a spreadsheet). For the client to know where their money is going, they should be able to read the issue business requirement and immediately understand it. This isn't the job of the PM on the project, this is the job of the engineer working on the issue as they're the one most familiar with it. If you need help expressing the business value of the technical work you're doing, contact your PM and they can give you a hand.

Business Value add instructions

Must be a one liner

don’t write a whole detailed description of the requirement and the reason behind it and the background etc. Simply state the business value of what the task is about.

Must be a parent task

No need to write business requirements for subtasks. The business requirement for the subtasks can be inferred from the parent task

Must explain the business value add, not just describe a problem

People don’t pay engineers to report a problem. They pay them to fix it. That’s why the business value add section should simply state the value added by doing it.

Bad example Users won't be able to successfully checkout using valid credit cards.

Good Example Fix bug preventing using from successfully checking out by using valid credit cards

Must use the imperative mood

This is best explained here. Similar to the git commit messages, business value should be written in imperative mood, which is “spoken or written as if giving a command or instruction”. A few examples: Clean your room Close the door Take out the trash Please see above link for more thorough explanation

I have used this policy with several teams/startups with mixed results. But I was going over the book Software Requirements and it showed this image:

and it shows "business requirements" as high level business objectives that belong in the vision and scope document, rather than "functional requirements specification" doc.

Question

Does it make sense to ask engineers to put a Business Value Add section in each issue they work on? Let's assume that engineers aren't trained for that kind of documentation (from my own experience, it's a hit or miss chance that engineers will be able to properly write a business requirement section, most of the time they do it just as getting through the motions and they don't really do a good job) then the next question is: does it make sense for anyone to write a business requirement section for each issue.. be it a BA or a PM etc?

Update

I just wanted to clarify something. Basically I guess my question makes more sense if given the context that the engineers doing the work are not from the same organization that's paying for the work. Classic example: entrepreneur outsources software work to a software shop, and pays them. The question I get all the time from such entrepreneurs is: where is all my money going? By requiring that the outsourcing company fill in the business value add section (and this is why it doesn't have to be an engineer doing it.. it could be the PM/BA from the outsourcing company), then the client gets a lot more visibility on where they're money is going, and I think that's fair (it better be, the client can simply make that a requirement when signing the contract).

Answer 1

Here's my TL:DR answer: No!

The engineer shouldn't be working on something if the business value isn't already defined. It's the voice of the customer (product manager, product owner, business analyst) that should be defining the business value.

Said business value should be agreed to by the business before asking engineering to size the work for building and certainly before the engineer actually lays hands on the keyboard.

Answer 2

Leadership 101: Do not force the team to do something for the sake of doing something.

On the surface, it seems to be a very nice idea, being poorly implemented.

The straight answer for the question is no - it does NOT make sense to force engineers (coding-oriented people, who usually have collosal knowledge on programming but low communication skills) to proceed with this painful exercise (for them) for every tiny change.

It DOES make sense, however, to have this kind of feedback from them whenever 1) engineers are not sure about what's being tried to achieve or 2) for the critical, complex requests that could lead to confusion.

There'll be stories missed here and there that could've benefited from this exercise, definitely... but in general it will be a less painful process to miss that story than force the Engineers to deviate the effort from where they master into something that could add low value to most of the Stories (assuming Stories, of course, are minimally understandeable).

Answer 3

this is the job of the engineer working on the issue as they're the one most familiar with it.

Technically, no. The engineer working on the issue is the one most familiar with the technical details of said issue. The one most familiar with the issue itself would be a Business Analyst (BA). Furthermore, engineers often have different priorities. I would not be overly surprised to find a 'business value add' section written by an Engineer as thus:

"Do this stupid, messy workaround so that the lazy and/or stubborn users don't have to improve change their workflow."

Which is (probably) not what you want. Even if you do want to be informed when developers are questioning the veracity of an issue, this questioning should probably not go into the Business Added section.

If you have a BA, get the BA to do this one-liner. If you're a small company who doesn't have a BA and the Project Manager is overworked or nonexistent, then you could ask Engineers to accomplish this BA-task in addition to their regular duties, but recognize that this is not ideal.

Answer 4

Does it make sense to ask engineers to put a Business Value Add section in each issue they work on?

No, not really, but you may want to do it anyway. Ideally, the person who asked for the feature should be able to clearly state what value it provides. Engineers aren't necessarily the best people to say why a feature should be implemented. In fact, they'll often be the ones questing why a thing is valuable. However, it is a great exercise for us software developers. It gets us thinking about value add.

Also, it just doesn't make sense to try to write value add statements about fixing bugs or technical debt. Maybe the tech debt, but most folks prefer a culture where you don't have to justify quality.

Does it make sense for anyone to write a business requirement section for each issue.. be it a BA or a PM etc?

Yes. It makes complete sense for a BA to write value add statements to a feature. If you have BAs at your org, they're the folks most in touch with your users and the business value.

In the general case, it makes a ton of sense to explicitly state the value of each item in your backlog. If the value can't be clearly stated, then the need to actually implement it is highly questionable. This practice will prevent you from wasting time on features no one needs and help you get the ones people do need right. I've experienced dozens of times someone asked for an implementation instead of a solution to a problem and we missed the mark because of it. Explicitly asking about the value makes it more likely the implementation will solve the real problem.

Answer 5

This would make sense if the engineers were deciding which issues to work on, rather than being told what to work on. If the engineers are deciding what to do, they should be able to concisely explain why. If someone else is telling them what to do, that's the person who is in the best position to explain the business value that caused them to assign that work.

The instruction that the engineers should write them, and consult their PM if they aren't sure how, sounds interestingly as if part of the goal is to get the engineers to be able to think in terms of business value, which is something that happens more naturally in agile development when devs are presented with user stories that include business value.

and it shows "business requirements" as high level business objectives that belong in the vision and scope document, rather than "functional requirements specification" doc.

But functional requirements should trace to business requirements.

Answer 6

This is not a job for the engineer or developer.

If you don' have BA's in your organization then whoever is receiving the project from the customer (project manager, account manager, sales) should be working with the client to clearly define the business case, user stories and acceptance criteria for the issue. You may have a common business case across multiple issues, but each has user stories and acceptance criteria specific to the issue.