Aryan has been the product owner in a large financial organization for the last 18 months. After finishing his B-School, he found it slightly hard to get the grasp of story writing. He invested time to understand and empathise with the users goals and priorities and features and stories started flowing.
Now, he has good experience in understanding the customer expectations and creating stories from the user point of view. He also had taken Jake as his mentor to review the stories prior to involving the team during the refinement.
After working in 18 months in functional development, the product that he was working on, need to complete a huge ‘technical work’ thats upgrading all the systems to Windows 10 and the required certification as well. While he has had a good understanding of what the application was doing, he found it extremely hard to understand the nuances of OS upgrade.
Jake has also been telling that all his stories for the OS upgrade sounds like a Technical task and not like a story. When he goes to his team, they are able to provide what needs to be done and there are no personas for whom he’s working on.
So how would technical stories be written and what are the best ways to prioritise them? Bigger question in Aryan’s mind is, is there a need to write technical work as stories? What is the value in it.
Have you encountered such a situation? How did you manage them?
Suggested Solution:
It’s a common perception among agilists that all stories need to business centric and they are the only valuable stories. While all the stories that are user centered are valuable, it is not correct opinion to have all technical stories are not adding value.
While creating a beautiful building, It’s apparent for everyone to build a proper foundation and structural elements while having focus on the bigger picture and the aesthetic elements. In the same manner, balance is key to ensure that technology foundational elements are given priority while working on business functions/value.
While value for business functions are measured by way of future potential such as new customer addition, operational efficiency, brand recognition there are similar ways to measure technical value also.
As a Product Owner, Aryan should not be giving undue importance only for the business functions at the cost of technological view. Here are the few categories to measure foundational value
- Risk of obsolescence: While using older versions of software, it could increase the risk of future proofing the foundations that you are laying it. In simple terms, this is considered repair work when done on a regular basis. The same would turn into a mega program if you do it after a major collapse.
- Non-functional requirements: Initiatives to improve security, performance and scalability to get the cross functional requirements to be laid out and the required software to be upgraded.
- Time taken for development: Some tech debt items would come under this category. Due to the nature of iterative development, emergent architecture leads to architectural and technical debt that needs to be paid off regularly.
While writing technical stories it’s important to go back to basics.
Independent: Story can be played separately
Valuable : As described above – Risk, NFRs, Dev time
Estimable : Ability to estimate the amount of work
Small : Small enough to complete within the iteration
Testable : Manual and Automated tests can be run to validate regression
With the changed I-Vest technical stories can be written in a meaningful and understandable fashion by Aryan and his team. It should always answer the ‘Why’ is it being done rather than ‘What’ is being done.
And given that all the technical stories don’t have a direct end user impact, personas can be safely kept aside. Instead, refer the product or the application only.
Construct of a technical story to be
Title of the story – Impact of the story
For e.g.
– For the application ABC, Change the interface for outbound from FTP to SFTP for XXX, so that security compliance can be met
– For the platform XXX, Java upgrade from 8 to 9 needs to be done, to leverage the ABC features for the next release
