As a change consultant, I help organizations through what I will refer to as "agile transformations." My experience in writing user stories like those proposed in this article is excellent for framing the requirement, putting yourself in the right frame of mind, and bringing consistency to the planning process.
How exactly you write the user story (or requirement) does not always have to follow the exact word-for-word writing that this article proposes. Keeping the who, what, why, value and definition as a mental template is super helpful.
For example, I recently had a senior person wanting to build a bunch of new reports. They were spending a lot of unbudgeted money to drive new potential customers to their trade show (they had too many existing customers and wanted to onboard more customers). They requested new reports, changes to how we manage all our customer data, and potentially purchasing some new software that could help track all of this.
Their requirements spread across multiple teams with different requests and a lack of a cohesive strategy. The leader was trying to make things happen because they were taking a significant risk and wanted to measure the value of this big new budget spend. However, how the requirements were communicated, it would have taken multiple teams many months to complete. We took this as a training opportunity.
After asking some questions and thinking through the process, we already had all the systems in place; they just didn't know it. We mocked up the request in the form of a few reports, and they said, "Yes! That is what I want!". We took a multi-month effort and brought it down to two dashboard reports with a few minor modifications to the marketing software we used. The entire request took two weeks to complete, with a few minor bug fixes the following two weeks.
We walked the executive through the user story, which looks something like this:
As the lead for our big trade event, I require metrics that prove our planned X, Y, and Z marketing efforts has increased the number of new potential customers over existing customers.
The title of the Jira ticket had a label like this:
"New vs. existing customer differential dashboards"
The ticket details included a copy/paste of the leader's original user story. However, the ticket had more detail, such as assumed systems impacted, databases to access, and teams likely impacted. That additional detail was maybe a page long so the team could understand how we translated the requirement into something useful for engineering and report writers.
By demonstrating how to think about the request and share our process through a simple user story format, the leader better understood how to communicate with these select teams. Now, that leader understands the process, writes down their requests in the style of a user story, and then meets with the product owner to work out the details and the value.
I do agree that the format helps other people be on the same page with the team. It can also make it easier to communicate and understand a specific requirement for non-technical people.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As a change consultant, I help organizations through what I will refer to as "agile transformations." My experience in writing user stories like those proposed in this article is excellent for framing the requirement, putting yourself in the right frame of mind, and bringing consistency to the planning process.
How exactly you write the user story (or requirement) does not always have to follow the exact word-for-word writing that this article proposes. Keeping the who, what, why, value and definition as a mental template is super helpful.
For example, I recently had a senior person wanting to build a bunch of new reports. They were spending a lot of unbudgeted money to drive new potential customers to their trade show (they had too many existing customers and wanted to onboard more customers). They requested new reports, changes to how we manage all our customer data, and potentially purchasing some new software that could help track all of this.
Their requirements spread across multiple teams with different requests and a lack of a cohesive strategy. The leader was trying to make things happen because they were taking a significant risk and wanted to measure the value of this big new budget spend. However, how the requirements were communicated, it would have taken multiple teams many months to complete. We took this as a training opportunity.
After asking some questions and thinking through the process, we already had all the systems in place; they just didn't know it. We mocked up the request in the form of a few reports, and they said, "Yes! That is what I want!". We took a multi-month effort and brought it down to two dashboard reports with a few minor modifications to the marketing software we used. The entire request took two weeks to complete, with a few minor bug fixes the following two weeks.
We walked the executive through the user story, which looks something like this:
As the lead for our big trade event, I require metrics that prove our planned X, Y, and Z marketing efforts has increased the number of new potential customers over existing customers.
The title of the Jira ticket had a label like this:
"New vs. existing customer differential dashboards"
The ticket details included a copy/paste of the leader's original user story. However, the ticket had more detail, such as assumed systems impacted, databases to access, and teams likely impacted. That additional detail was maybe a page long so the team could understand how we translated the requirement into something useful for engineering and report writers.
By demonstrating how to think about the request and share our process through a simple user story format, the leader better understood how to communicate with these select teams. Now, that leader understands the process, writes down their requests in the style of a user story, and then meets with the product owner to work out the details and the value.
Thank you for sharing your experiences!
I do agree that the format helps other people be on the same page with the team. It can also make it easier to communicate and understand a specific requirement for non-technical people.