Cancelled User Story vs Burndown vs Velocity
Hi folks,
my team has technical (kind of explatory) user stories. In the current sprint, one of this story has been cancelled due to more research is needed AND there is a dependency to a work item that is not yet planned.
The PO agrees to remove the user story from the current sprint for further analysis.
As 1 or 2 hours have been put on this story, removing it will clean the burndown of the remaining work on this item, but will not be transparent to the stakeholders as it was planned points.
But if I removed it, the team will "lost" the corresponding user story points, and final velocity will be affected as they will not be delivered.
I have to say, it can appear as a moot issue, but as the team will face stakeholders and as we are in a transitionning organization, all agile concept are not well mastered. And we're using JIRA.
I would tend to remove the story and its points altogether with time lost regarding the burndown but it will not put stress on the team as those points will have to be delivered in an another sprint.
But in the same time, I have my other side saying we should keep it as is and show it is a cancelled story to everyone. But then the team will suffer of not "delivering" what they said they will (and what the stakeholders (mostly IT director new to agile) are expecting to see delivered).
What should I do regarding this story ?
I am looking to this particular answer as I am already already aware (and have plan) that more agile teaching upwards and retrospective workshops will look into the root causes.
Thank you for your help !
Can you explain in more detail how you "deliver" story points? Aren't they just for estimating and forecasting?
Isn't it a valuable increment that meets a Sprint Goal which gets delivered? Isn't that what the PO and stakeholders would wish to see?
You're totally right. As mentioned, the organization and the department i am in, are in transition. So they still associate points to deliver instead of pure business value. And I misused the terminology here also.
AS a new scrum master there, I have also to adapt to the context before starting to make changes. This is a top priority in my list as for instance, we do not fill the 'business value" part in Jira cards. I could go on and on on all the discrepancies we can note here ;)
But by your answer I conclude that this is indeed a moot issue and therefor should not waste more time on it.
Be Transparent!
Hello Eric, I am a Novice in this area and have to start my track record yet. One of the pillars of scrum is Transparancy, so share this learning point with your PO and discuss how to administrate and communicate this. Do NOT hide this by deleting it from the administration. There is good work done and it will pay off in a later sprint.
Edward
There is no requirement that every story must be fully delivered within a single sprint. A sprint can include foundation work on stories to be delivered in subsequent sprints.
If that sounds wrong, search your Scrum guide right now and see what it says about stories. Surprised?
User stories are groomed to be as modular as they can be and still bring user value; developers break stories down into logically sequenced sprint backlog items, each of which is smaller than the story it belongs to. Sprint backlog items don't become product backlog items -- they are associated with the feature, function, requirement, enhancement, or fix that the product owner prioritized.
It sounds to me as if the developers began work on the story and have a new, better understanding and idea for the work items and effort needed to deliver it. That is work that has been done toward delivering the story. Transparency demands explaining that.
The good news is, the team knows more than they used to about what it will take to deliver the story! Unfortunately, it's a little different than y'all originally thought, but that's what happens when you design cool new stuff. Any team can accurately forecast the effort to deliver the same old same old, but who wants that?
What you did was probably JUST RIGHT. Agile maximizes the amount of work NOT done: yes, we groom the backlog, but not to the nth degree for every feature that MIGHT be delivered someday; instead, we scan what is bubbling up but take a chance on how much analysis we can defer until the PO pulls the trigger on the feature. Otherwise we would kill time and (worse) passion figuring out work that never makes the cut. Most of the time the team can smell trouble and they know where to dig in. Sometimes, we get it wrong. If the only mistake is in what you thought, not in what you did, let it go -- own the mis-tossed dice, and move quickly to showing the stuff that works. Woohoo!
(I ran across a team once that had labeled every identified work item a "story" in order to fit each one in 2-week sprints and had the product owner prioritize all 1500 items...up front. Table creation wasn't important to the PO, who wanted to see UI...so the developers built the UI but did not build the tables and DB functionality that the PO ranked lower in priority. Try keeping a straight face while a "Scrum" team tells you that!)
Have you ever considered to attack those 'research' stories in backlog refinement events? You can do them up to 10% of the teams time, which is around 1 day per 2-week sprint. You can use those refinement events, for instance to take a group of devs and let them brainstorm/explore a technical user story. Away from computers, in a room full of whiteboards. Timeboxed to an hour!
This sometimes helps *a lot*
Greets
M
You could address those more technical user stories during backlog refinenment (<=10% of dev team time per sprint). Take a room, put it full of whiteboards, and let the devs together brainstorm and split up difficult, big, technical user stories into small, actually achievable user stories.
Of course PO should first prioritise. No need to analyse potential feature X if its low on prio