Scoring overall user stories
Hello,
We have decided in our sprint planning to create one overall story for features, with then 2 child issues relating to the different platforms we support,
If both child issues are labelled as a 3, would you just round up the total story points as either a 5 or an 8 scenes as there is no 6 in the fibonacci sequence?
Thanks
Is it the overall item or the constituent item which would be Done in a Sprint?
Remember that the only purpose of estimation is for Developers to get their arms around how much work they can take on each Sprint, with at least one Done Increment then being created. We are not in the business of being story point accountants.
What benefit would you get from adding the two separate work items' estimates? In your implementation the overall story is just a wrapper for other stories that will define the actual work.
To support @Ian's statement, once the Sprint starts, the estimates are no longer useful. They are estimates made at a point in time based upon the known information you had.
Hello,
The idea of estimating the subtasks on the "User Story" is to allow line managers to track individual developer performance across all the boards whilst also allowing the team to keep track of the overall user story to a more detailed level.
I take both of your points on estimating the story at a place in time with the information you had so thank you, I think I need to get across to the wider business the focus point should be on "Estimation" and that you should not be looking to account for stories being underestimated by 1 or 2 points.
The idea of estimating the subtasks on the "User Story" is to allow line managers to track individual developer performance across all the boards
Just read that back again and reflect upon the issues being exposed. There isn't just an issue with what is being estimated. There are managers who are trying to track the performance of individuals -- using estimates of all things -- when in Scrum it is valuable increments which are delivered, and by Developers who are collectively accountable for their work.
There may be an opportunity to reflect upon the Scrum values with those managers, perhaps starting with respect.
You know what's going to happen? And I've had this happen to me as developer...
The developers are going to estimate stories higher and higher, and then an expert will be asked to correct the estimations.
The end result will be some external "architect" will be estimating the stories, while the developers get blamed because they don't get the velocity wanted and they can't get the user stories developed in the time "they" estimated. And then management asks why the developers leave the company.
If they didn't do this to us, the development team of the organization I worked at the time for would not be reduced from 7 to half a person now. Please, please, please, stop calculating the performance of software developers.
Here is an article that might be helpful
https://www.scrum.org/resources/sd-times-guest-view-dont-use-velocity-weapon
Hi Adam
Our objective is to complete the feature or in Scrum we called it "done"
if your definition of done is by platform then we shall track it individually, so please define "what is done" first
Based on my experience each platform will required different interface, testing and most important stakeholder
If there is a different stakeholder, I recommend to track it as separate object to better manage the future request and development