Requirement/story building tasks
I've worked on a few Scrum projects now but have always been move involved with or lead the development (implementation) side of things based on stories that would magically appear on the backlog. The development of the stories would be discussed in stand-ups but not tracked as tasks on the board.
On my current project, I am leading the requirements gathering as well as the implementation and am looking for some advice around best practices for tracking the analysis/story building tasks vs. the development tasks.
This is a data migration project so there is arguably more work in developing the stories/requirements than actually implementing them.
My first inclination is to develop user stories specific to the requirements gathering similar to this: "As a business analyst, I want to map customer fields from source system 1 to the target system schema so that a developer can implement the mapping."
This would then allow another PBI to be created with a user story for implementing the customer field mapping.
My questions are:
1 - Does this approach make sense?
2 - Any other approaches?
3 - Is it normal not to track "story building" tasks as part of a sprint (this has been my experience)?
thank you,
Kevin
> Is it normal not to track "story building" tasks as part of a sprint
Product Backlog items should deliver value to the Product Owner. If they are written as user stories, this implies that each story will deliver something of value to business stakeholders. The value of the stories inducted into each and every sprint must be potentially releasable as an end-of-sprint increment.
Authoring PBI's that don't contribute to the potentially releasable value of increments is something to be avoided. It would be better to conduct product backlog refinement sessions, in which requirements are brought into a fit state for Sprint Planning and forecasts can be made. This is the mechanism that the Scrum Guide provides for.
A common challenge while writing user stories is to handle a products non functional requirements. Its about an attribute and characteristic.
http://grannyflatsolutions.com.au/projects/
Hey Kevin,
Sounds like there is a firm separation between traditional development and design in your team? As Ian points out, the user story should result in (part of) an increment that consolidates to your Definition of Done and adds value to the business. Try to incorporate all the effort to deliver this value in a user story.
The plan for delivering that piece of functionality could be worked out as tasks that the development team sets up. These tasks represent all the work that needs to be done to complete the user story. It also helps to track progress during the sprint.
Thank you all for the feedback - the key gap here is one that I've seen often, especially in government and large enterprises coming from a waterfall model.
Business Analysts are building user stories which is good but their time to develop these stories is not tracked or planned for in a trackable way.
We are using a TFS scrum board and have created user stories for development which are the result of a BA user story about developing the requirements which feels wrong but is required so that stories don't span sprints and we can track the BAs effort.
Is there a better way to track the total effort, recognizing that non-agile organizations often can't build valid requirements quickly?
thanks,
Kevin
Hello - I am new to SCRUM, am interested to understand (and/or confirm) that the product owner is the one who writes the user stories. Then as presented to the Development Team, these can be updated further into requirements?? Please help me with clarifying who does what, and when..etc.
Hello Cynthia, Its true that PO is the one who is responsible for the stories or PBIs but it can be written by PO or Dev team or Scrum team as whole. Point to remember is it doesn't matter who writes them but the end responsibility lies with product owner.
Now for the second part, user stories or PBIs ARE the requirements, you will not have any other artifacts, product backlog should be your only list of items to build the product. Product backlog is always evolving and anything can be added to it at any point of time. PO must make sure the newly added items are prioritized accordingly based on business needs. He then takes these user stories/PBIs to Development team for discussion and estimation in the ceremony called product backlog refinement, you can find more about PB refinement in Scrum Guide.
He then takes these user stories/PBIs to Development team for discussion and estimation in the ceremony called product backlog refinement
Actually, Product Backlog Refinement is not one of the ceremonies/events in Scrum, but is an ongoing process left up to the Scrum Team to decide when and where.
@Timothy - Yepp thanks for highlighting that, I meant its an event/process.