help in estimation and story breaking
Example: one feature comes that needs to be built:
-> Team divides into 3 stories
1st story - 13
2nd story - 8
testing story - 8
------
the reason we create a separate testing story, is to not show such huge nos. on the board
we could not have created 1 single story and showed pointers as - 13 + 8 + 8 = 29
neither, 13 + 8 = 21 ( inclusive testing), another 8 for remaining
instead i follow, 3 stories with their effort as i showed above ( 13-- 8 --8)
Now my supervisor says, in jira board , where estimation goes, use this instead 8 + 8 or 13 + 8 to show it includes testing. Not fully convinced. Need your inputs.
the reason we create a separate testing story, is to not show such huge nos. on the board
@Rhea Pillai, Everything that you said raises a lot of red flags, including the above statement. Consider how this impacts transparency.
Why do the numbers bother you or anyone? Is the Development Team collectively confident that they can complete this feature in one Sprint irrespective of the numbers?
On a side note, testing shouldn't be done separately because can you really consider untested work as potentially releasable?
ok, so do you mean i can create a story and mark it as 29 pointer (that includes entire dev and testing effort)
ok, so do you mean i can create a story and mark it as 29 pointer (that includes entire dev and testing effort)
@Rhea Pillai, Let me ask you this in a different way. Forget about story points for a moment. Can your Development Team collectively complete this feature within the timebox of your Sprint such that it meets the DoD (which means testing included)?
i can create a story and mark it as 29 pointer (that includes entire dev and testing effort)
Assuming the team can complete it in one Sprint and meet their Sprint Goal, why not do exactly that, and during Sprint Planning break it down into units of one day or less as described in the Scrum Guide?
What use are those numbers to you? There are no fixed rules about how you use story points (if you even use them at all), but if you're getting into disagreements about how these numbers should be added up, there's probably some other dysfunction that stops you getting the real benefits from using story points.
For instance, imagine I have a journey from Amsterdam to Zagreb, and I've estimated it at 13 points.
Historically I've found that 13 points is way too much to tackle as a single journey, so I decide to break it down into smaller units.
So I break it down into 4 smaller journeys: Amsterdam to Cologne (3 points), Cologne to Nuremberg (5 points), Nuremberg to Graz (5 points) and Graz to Zagreb (2 points).
There is a slight increase in work, as I make some minor detours, but the main reason the overall estimates are higher (3+5+5+2 > 13) is a quirk of Fibonacci estimating. I could split Cologne to Nuremberg into Cologne to Frankfurt, and Frankfurt to Nuremberg, and the 5 pointer will be replaced with 2 lots of 2 points.
Either way, I'm left with several items that are more manageable. I will be able to measure progress sooner, and project how long it is likely to take me to reach Zagreb, and potentially use that information to decide whether or not it's even a good idea to continue to Zagreb, if it looks like I won't make it on time.
Often story points are abused to demonstrate the amount of work done. They're ineffective at that, and I challenge why it's important to measure work done, rather than value delivered.
In my experience, the main benefit of story points comes when you break your work into units of a manageable size, so that you can have a predictable workflow, that then allows you to inspect more frequently and change direction when it's needed.