Problem how the story is developed
Hi All,
I faced an issue with my dev team and the product owner a couple of months back. I thought of putting it here to get ideas on how to deal with it, if same thing occurs in future.
Our sprint started on 6th Feb and ended on 19th Feb. We usually do a 2-week sprint wherein we get a total of 10 working days. We do have a heart stop where we don't do any development work after the 8th day since the last 2 days are meant for pure testing.
15th Feb was the 8th and last day of our development work. Now, one of our stories was pushed to QA on this day for testing. Our product owner who has the access to JIRA, using the QA link checked the look n feel of how the story has been developed and gave a feedback to change the UI a bit. On this, the developer said that it is too late in the dev cycle for them to go back and change it since the effort they have put in so far would go wasted. However, the PO was adamant and said he would then put another story in the next or future sprint to get that changed.
In my opinion, since I don't know the technical effort this change would have called for, I had to agree on the effort estimation the devs gave me. They said that this is too much of rework. Both the devs and the PO had a different story to tell in terms how this was decided in the first place in refinement sessions. The story in JIRA doesn't contain any information on how this should have been developed, which in my opinion is a MAJOR MISS. If the discussion happened on the design, the PO should have gone back and modified the story to reflect the changes.
I believe, this could be a learning and would be helpful in being more diligent with using JIRA. However, the question at that point still remained the same whether or not to make any changes to the story to reflect the feedback given by the PO. If he does create a story in the next sprint to get it rectified, the devs effort still goes wasted indirectly. We usually do our deployments on Fridays which in this case would have been 23rd Feb.
I am not really sure which side to get inclined too? In my opinion, yes the PO didn't mention the details in the JIRA which he has got the learnings from. But we as a team should focus on delivering quality work. Delivering something which we know for sure is going to go for a logic change in the immediate sprint, I would have liked the developers to accommodate this as a one-off exception this time. Please suggest.
The devs however in the real situation didnt pick the work and agreed to rework i next sprint.
Thanks
On this, the developer said that it is too late in the dev cycle for them to go back and change it since the effort they have put in so far would go wasted.
Why was that waste allowed to accumulate? Why wasn't the PO involved in discussions about how to best implement the story? A user story is not a specification, but a placeholder for a conversation about a possible requirement.
However, the PO was adamant and said he would then put another story in the next or future sprint to get that changed.
Why does the PO think he can "put" stories into a Sprint? Isn't Sprint Planning a matter of negotiation between the Development Team and the PO, with regard to how best achieve a Sprint Goal?
In my opinion, since I don't know the technical effort this change would have called for, I had to agree on the effort estimation the devs gave me.
Why and when would you ever disagree? Aren't estimates entirely a matter for the Development Team anyhow?
They said that this is too much of rework. Both the devs and the PO had a different story to tell in terms how this was decided in the first place in refinement sessions. The story in JIRA doesn't contain any information on how this should have been developed, which in my opinion is a MAJOR MISS. If the discussion happened on the design, the PO should have gone back and modified the story to reflect the changes.
I believe, this could be a learning and would be helpful in being more diligent with using JIRA
It sounds to me like there is a lack of collaboration between Scrum Team members, and that the Sprint is being conducted in a mini-waterfall or stage-gated manner. It's very unlikely that there's an underlying issue with JIRA, in so far as the tool is just reflecting a problem back at you. The problem being reflected is one of process and organizational culture.
It seems with the issue as presented, there are several items which bear further review/discussion:
- Figuring out a way for your PO to view completed items earlier in the sprint (not on the 8th day) may help mitigate the impact of suggested changes
- As Ian alluded to, a hard development stop on the 8th day of a sprint is indicative of a mini-waterfall approach, which is a bad smell in Scrum. The Dev Team should be able to make changes and test all the way up until the end of the sprint
- Estimates are meaningless unless they originate from those doing the actual work. It is also important to keep in mind that these are estimates (best guesses) based on the information on hand
- It sounds as if either a UX requirement was missed in refinement, or the PO changed their mind mid-sprint. Either scenario begs a discussion in the retro on how to prevent such lack of clarity in the future
- The PO may offer the missed UX requirement in the next Sprint Planning, but that needs to be negotiated between the PO and the Dev Team on whether it becomes part of the next sprint. One question is - does the missed UX requirement completely render the delivered work product having zero business value?
On this, the developer said that it is too late in the dev cycle for them to go back and change it since the effort they have put in so far would go wasted.
Why was that waste allowed to accumulate? Why wasn't the PO involved in discussions about how to best implement the story? A user story is not a specification, but a placeholder for a conversation about a possible requirement.
rhea:- As i mentioned, the way it should be developed was discussed in the meeting but nowhere documented which led to misinterpretations. The PO in his feedback requested to change the UI which the devs didnt agree to since they both had different versions of the how part in their minds.
However, the PO was adamant and said he would then put another story in the next or future sprint to get that changed.
Why does the PO think he can "put" stories into a Sprint? Isn't Sprint Planning a matter of negotiation between the Development Team and the PO, with regard to how best achieve a Sprint Goal?
Rhea: Agreed. But if the devs didn't agree to change the UI for the story in the current sprint since that would call for rework, he says we still need to rectify it in the future sprint. The devs say if the UI again needs to be changed they should be having another story.
In my opinion, since I don't know the technical effort this change would have called for, I had to agree on the effort estimation the devs gave me.
Why and when would you ever disagree? Aren't estimates entirely a matter for the Development Team anyhow?
Rhea: Agreed. Just sharing the thought. There was no question that was put to them.
They said that this is too much of rework. Both the devs and the PO had a different story to tell in terms how this was decided in the first place in refinement sessions. The story in JIRA doesn't contain any information on how this should have been developed, which in my opinion is a MAJOR MISS. If the discussion happened on the design, the PO should have gone back and modified the story to reflect the changes.
I believe, this could be a learning and would be helpful in being more diligent with using JIRA
It sounds to me like there is a lack of collaboration between Scrum Team members, and that the Sprint is being conducted in a mini-waterfall or stage-gated manner. It's very unlikely that there's an underlying issue with JIRA, in so far as the tool is just reflecting a problem back at you. The problem being reflected is one of process and organizational culture.