Hi âŠ
Post by ***@yahoo.com [SCRUMDEVELOPMENT]I am in between my Sprint n the team is fully functional. My product owner just found n informed that some of the user stories from the ongoing sprint might not add business value or r obsolete n wants the team to replace them with a new set of features which r not yet estimated.
I need to begin with a few observations about how concerning this is.
First of all, the Product Owner is totally responsible for maximizing the value of the Sprint and the whole effort. So it is quite concerning that, a week or so ago, the PO asked you to do these things which have suddenly been found to be of no value and/or obsolete. This makes me think that you do not really have a Product Owner at all.
Post by ***@yahoo.com [SCRUMDEVELOPMENT]The team has already completed their coding n is now trying to integrate test it.
This tells me that the team is developing in an odd way: code all the features, then integrate then test. It should be well known by now that the thing to do is to build one feature at a time, all the way to fully integrated, then do another and another. This makes me think that the team is not yet very capable.
Post by ***@yahoo.com [SCRUMDEVELOPMENT]How do v handle such scenarios or requests mid Sprint ? Should i accept these new features?
You do not mention what your role is. Scrum says that the Dev Team decides, during Sprint Planning, how many features to accept, in priority order. Unless you are the whole Dev Team, which seems unlikely, Iâm not clear why you are in the business of âacceptingâ features.
Scrum also makes absolutely clear that changes are not accepted during the Sprint. Your Product Owner has two options: let the Sprint continue until done, or cancel the Sprint and plan a new one. I think a wise Product Owner would consult with the team on this, but since the Product Owner has the unique responsibility of maximizing value, terminating the Sprint, or not, is their sole decision in my opinion.
Post by ***@yahoo.com [SCRUMDEVELOPMENT]My take would be to stop r minimize the obsolete features but continue with the remaining features of the Sprint without shortening the Sprint n later consider the new list for the next sprint?
If the Sprint is to continue (which IMO is the POâs decision) then it would certainly make sense to stop working on the useless features and to continue on useful ones if there are any. This will probably result in having more capacity in the Sprint, and the team (THE TEAM) could decide to take on more work without much of a problem. This is commonly done when a team discovers they have too little to do. Scrum does not speak directly to this case in the Guide but most people consider it to be a reasonable thing to do.
Post by ***@yahoo.com [SCRUMDEVELOPMENT]My po is very particular to replace them now itself. What is ur / scrum framework take here? There could b a discussion that if i continue with the current planned features, its a waste of effort n budget as v should anyways rework to include new features later. But if i agree to the changes now, i might be sending a wrong message which cou
ld become a practice to my po to request similar changes in future n my team might get demotivated. Kindly advise.
You keep referring to âmy teamâ. I donât know if that means âthe team I happen to be a member ofâ or if you are expressing some form of ownership. Scrum does not have the notion of a Dev Team Owner. It does not have the notion of a Dev Team Lead, who would not own the team anyway. It does not have the notion of a Dev Team Manager, who would not own the term either. The ScrumMaster is a servant to the team, not its owner. Anyway ...
The Product Owner has the sole responsibility to maximize the value of the work. If the work being done is invalid, the Product Owner has the right and duty to stop it. There is no role in Scrum that can override that decision. If the Product Owner says stop, you stop.
Now then, we need to figure out what has gone wrong and deal with it. This is a job for the Sprint Retrospective. Please write soon and tell us how your retrospectives are going. The ScrumMaster has the responsibility to see that this problem is resolved. Here are some thoughts regarding what may be going on.
One possibility is that your Product Owner may not really be empowered to decide what to do, and may be taking orders from someone else who is the ârealâ Product Owner, and who gets involved only rarely (since apparently a week or so ago, no one knew that these features were bad ideas). If this is the case, there will be waste like this more frequently. While team motivation will be at risk, a more important fact is that money is being wasted. If half your Sprint has been cancelled, the Product Owner has wasted that much money. In the USA that might be as much as $15,000 or more per team week. This fact may be more convincing to the people you need to influence than mere morale, though it should not be.
Another possibility is that the Product Owner is not competent at judging business value. In this case, they need help. The team can help: it is likely, if these features were bad ideas, that someone on the team knew it. It should have come up in Backlog Refinement (you are doing Backlog Refinement, are you not?) that these were not valuable features. If no one knew these features were not valuable then your team is not properly constituted: the team must include all the skills necessary to do the job and this includes analysis and evaluation. If the fact that these were bad ideas and no one mentioned it, then we need to look at whether there was an opportunity (Backlog Refinement) or not, and if there was, why the people did not speak out. If they spoke out and were ignored, then the Retrospective needs to address why important information is being ignored, at great cost in time and money.
So there are quite a few possibilities as to just why this has happened, and they are all the responsibility of the full team, Product Owner and Dev Team, to identify and resolve. What to do this time is probably not very important: I would be inclined to stop the Sprint because it is more dramatic and it appears that your team needs a whack upside the head to get things sorted out. But youâre there, and Iâm not. One way or another, thereâs serious stuff behind this problem and it needs to be identified and rooted out.
Ron Jeffries
ronjeffries.com <http://ronjeffries.com/>
Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana