Question
Novitates Technology Solutions Private Limited
GB
Last activity: 30 Jul 2018 8:23 EDT
Where do i write detailed requirements in Agile
So as per Pega@Agile guide, user story is not a detailed specification. So my question is, if I have to have a developer work on a story, where do I enter all the nitty gritty details that he/she requires to complete the task?
Pega
US
Novitates Technology Solutions Private Limited
GB
So, if i need to add details like the drop down values, the data dictionaries, the validations that are required and other stuff does it not go into the story? I, acting as a business architect in my project, want the developer to use a certain feature in Pega, where do I mention it. Or it is entirely not my job to figure out the implementation?
Pega
US
If you're filling the Product Owner role, then ideally you're not supposed to specify how something should be implemented. You want to spend more time partnering with customers and researching the market to understand and clarify the use-cases, problems to be solved, and value to be delivered to customers.
It sounds like the role you're filling might have more technical responsibilities than a classic Product Owner. If that's the case, you should fulfill your role as designed, and you can partner with the team to define technical details (it's fine to capture these notes in the user-story). However, you should still begin the user story with a "As a ______, I want ______, so that ______" so that the problem to be solved is clear to everyone. Additionally, if you're trying to move more towards a classic Product Owner role, I would start to transfer your technical knowledge to the team, and as much as possible make it their responsibility to figure out implementation details while you focus on the previously mentioned items.
Howdy! Sorry for the late response.
What role are you playing on the team? Are you the Product Owner? If so, you shouldn't need to specify details for how the Story will be completed (aka, implementation details). Those details are for the engineer to figure out. As the Product Owner, you want to clarify in the story the Why (what problem are we solving, why is it valuable, what are the use-cases, why would someone care about this, etc.), and what Done looks like (what should a user be able to do as a result of the Story, how should the new feature function, what environment does the work needed to be deployed on, etc. - these are the story's acceptance criteria). The details of how the code is structured or implemented is for the engineers to discuss and figure out.
Does that make sense? If you Google "user story examples", you'll find plenty of information that may help. Mike Cohn is an especially good Agile Coach. This is an article from his website: https://www.mountaingoatsoftware.com/agile/user-stories