Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
A Business Analyst was asked to write a user story for a script change. The Dev and DBA were changing two letters in the script. I told the BA to put it on the Backlog as a task. He insisted on writing a story like, As a developer, ....
How are you other BA's handling technical request/changes to scripts that have no effects on the end user?
I likely wouldn't bother for a trivial change like this one (tho I would file a ticket: no invisible work), but I would for stories that added business value, eg,
as a developer I want to see more logging from the app so that it is easier to debug problems
as a developer I want to upgrade to the latest version of package X so that the code is more maintainable
I think it's particularly important to do this when you need to make the case to spend resources on such non-user-facing things which basically add business value that is invisible to most stakeholders.
I believe that the main responsibility of a BA is to capture the functional requirements which will add value to the customer. It is better to follow the 'INVEST' philosophy when writing user stories. In this case, we need to segregate this as a non-functional requirement. It is better to handle as tech task in sprint.
It sounds like you are probably using Scrum. Assuming that is true, Scrum refers to items in the backlog generically as product backlog items. User stories are one type of product backlog item but not the only kind. Furthermore, user stories are a specific technique that extends far beyond the canonical "As a, I want, so that". If they really wanted to create a user story, I suppose that's fine, but it should have expressed the user need. For example, "As a user with two accounts, I want to see my payments from both accounts on the same list so I don't have to switch back and forth." and maybe the implementation for this is just a 2 character change, but at least that would be a user story. If you're adding a backlog item to say "change these two letters", then it should probably read just like that. Doing an "As a Developer" is both wasteful and builds bad habits.
First, this change absolutely deserves to be in the Backlog. Second, if a BA has a good reason why it shall be created in a story format, then you can put it down as "As a server, I want to recognize one transaction service client from the other so that...".
Personally I'm fine if such requirements are not formatted as a story.
I want to add a new concept I've found mentioned elsewhere: developer experience. If a development task involves how "hidden system" works (most of the time), a good explanation with a clear statement that involves how systems will be improved, could help developer too. For example:
"As developer I want to improve continous integrations scripts to fully, so when deploy component X fails, dev team receive an email of errors"
This is something not related to end user experience, but improve how developers works and in particular dev (and devops in the example) process in general
How are you other BA's handling technical request/changes to scripts that have no effects on the end user?
This is something that often pops up in the real work that boils down to the similarities and differences between what're known as user requirements and system requirements.
As you can see, system requirements can be broken down into functional and non-functional requirements themselves. That said, even system requirements should have acceptance criteria (just like user requirements) to denote what the work should ultimately result in.
User stories can, in theory, be used to capture acceptance criteria for both functional and non-functional system requirements. Capturing these requirements in the backlog provides transparency into what's being worked on, the value it's projected to provide, and the level of effort the team has forecasted for the work relative to other work items.
So long as the acceptance criteria is present, the team has a goal to test against and build for in order to provide value.
At the end of the day, use what makes sense but make sure the goals for the new requirements are captured so the team has something to shoot for before calling it "done".
