Scrum Assessment Discussion > 28% correct ... Which two things does a ScrumMaster do if the Team doesn't have the engineering tools and infrastructure to completely finish any Product Backlog items?
I got a wrong answer on this one. I selected the third and the last item above.
I was mislead to think that having the Team define "done" and do the same work for all Product Backlog items it selects was a given.
The question invoked and urged in me a call to action. Although I would personally not practice number 3 as it is, during the test, "sharpening the saw before going to work" came to mind.
Brian Tan Seng
In retrospect, I can't believe I answered #3 as it's impractical. There are demands of the business that must be met and the quality of "doneness" may suffer as a result of improper tools and training, but that level of quality is situational to what is needed at the time. But to always allow the team all the time they needed is not the answer.
Max Keeler
I had been in the exactly same situation before. My first attempt to solve the problem was identical to three. The management wasn't amused about it and I had to figure out something else. In the end I came up with the two correct answers of the question above. Thinking about it now I totally agree with the answers and would never take another route, because everything else wouldn't comply with Scrum.
Wolfgang Wiedenroth
I also got it wrong and in a similar fashion. Now I realize that #3 is wrong. But given the test scenario and the time pressure it is difficult to realize that #3 is wrong.
Mayank
In my opinion there is enough time to think about the question. It took me half an hour to get a decent percentage on the quiz so that is no excuse.
Both of the correct answers together are reflecting every important principle of Scrum.
With the words of Ken's Scrum Guide:
1. Transparency - Define done and work with it. Everybody should know your definition of Done and why the team defined it that way.
2. Inspectetion - Based on your last inspect your work and see what skills, tools and infrastructure is needed
3. Adaption - Improve what you think is needed to do finish the backlog items.
In short:
Do the work and improve it
That's why they are the correct answers.
Wolfgang Wiedenroth
#3 reflects our desire for perfection before starting, rather than our tolerance of emergence under the harsh glare of inspection of our engineering practices.
Any suggestions on whether this is ok as is, or do we have to make the question more understandable?
Ken
Ken Schwaber
I think the question is worded fine. I think the answers represent a common misunderstanding in scrum, and as you say a desire for perfection before we get started.
Karen Greaves
while I was one of the folks represented by selecting #3 I think I chose that with the assumption in my mind that I would not just work on the infrastructure alone in a sprint all by itself but to do so by adding in technical debt burndown into all sprints. We all know we cannot just stop the work ( although sometimes that may be the prudent thing to do... but that is a business decision that needs to involve a larger context) maybe if the answers where a little more clearly defined or remove the word "any" for the question....if you cannot finish ANY backlog items you gott do something to improve the situation/remove that major impediment else you will always have difficulty and not really make the progress you can as a team. In all the team I have worked with there is always a steaming pile of technical debt, the white elephant, they do not want to talk about and it gets severely in the way of real progress till one starts to address it...and by incrementally chipping away at it more progress overall is made and a more complete and sustainable environment emerges
Johnny Scarborough
The way the question reads, I'd answer #2 and #3. Since we can't finish ANY backlog items, why even start? Tell the Product Owner we can't commit to any product-related backlog items and then create the infrastructure-related backlog items necessary so that we CAN complete product-related items... and then execute on implementing the infrastructure-related items ASAP.
If you do anything else, aren't you setting the team up for failure?
John Clifford
I agree with Karen. The wording is fine. The discussion here shows the question is balanced.
Wolfgang Wiedenroth
I don't feel the question should be changed. The wording may be tricky, but that seems essential to me. Because in a way it seems intuitively okay, but needs a bit of reflecting.
My considerations were that taking "as many Sprints as required" (1) looks an awfull lot like a desire for full upfront design, (b) does not take into account that the only progress is working software and (c) is NOT timeboxing -at Release level- (despite the use of Sprints).
Maybe this is a question that takes a bit longer to consider but I wasn't particularly stressed because of the time element (finished the assessment <26 minutes).
Gunther Verheyen
To eliminate item number 2, I remembered some points given by Ken on a Google Tech talk (http://bit.ly/2GKlxH).
If you have a team whose skills are totally mismatched with the product backlog, say having a team kindergarten kids in your project then you can still run the project using Scrum. Only that you produce crap each sprint.
Brian Tan Seng
I selected #3 on this and I still think it needs to be considered. In other questions you are expected to stick to a definition of done among multiple scrum teams, so I assumed you couldn't change the definition of done. So I discounted both the correct answers.
We've been using Scrum with embedded systems and, in the early stage we either have no hardware or we have incomplete features or interfaces (firmware). Also we're usually working in new environments so we need a lot of infrastructure. Answer #3 is what happened, for one sprint. We created a system that may be useful, at least for exhibition and sales demonstrations until we could get hardware and firmware that matched.
Apart from anything else, developing applications for embedded devices helps the low level developers; they have something to work against. So #1 & #3 still seem right for embedded and #4 & #5 seem right for business applications.
Perhaps we (ScrumIT) are bending Scrum too much to work in the device field, but it seems to make sense to our customers.
Mel Pullen
The best option, and one I've heard Ken Schwaber advocate more than once in person, is to break the PBIs into thinner vertical slices, and take on a smaller number of them.
If we lack skills in creating potentially-shippable products, let's generate a smaller amount of code while we're gaining those skills, rather than continue old habits generating tons of half-baked code. Get 5 small items done/done/done rather than 10 large items "code complete." Velocity will increase again after we internalize the new practices.
I suggest adding this option to the question.
--mj
Michael James
Can I be argumentative a while and ask who has defined the 'right' answer here?
If a user story has been taken on that can't be completed because of missing tools or infrastructure then there are two situations...:
a) The team knew this but also know how to get the required tools or infrastructure within the timescale of the sprint, so actually there isn't a problem.
b) The team didn't think things through enough during the sprint estimation before taking on the user story.
In situation (b) - the only one where there is a problem - the scrum master should first investigate whether there is a solution or workaround that can be deployed within the sprint. On one occasion I have used a Cadence emulator to pretend to be non-existant silicon so software can be run - a workaround, expensive, but enabled the sprint to be completed (at least to a very sensible point).
If there is no work around then I would suggest the scrum master needs to inform the product owner, between the two a decision on scrapping the sprint or reducing the user story list needs to be made.
The retrospective needs to cover what went wrong on this particular occasion.
If this sort of thing happens more than once then a check list system needs to encourage the team to think a little more deeply in the future.
As for the proposed answers:
a) Doing the best you can and dumping a half cocked mess on the product owner at the end of the sprint is not acceptable, the product owner should be involved as soon as the problem is apparent, and further involved in deciding the course of action.
b) One swallow doesn't make a summer, nor does one monumental ****up mean the team is incapable of doing scrum.
c) The only time that preparing the infrastructure/tools over a number of sprints is acceptable is when these are broken down into stories on the product backlog, agreed by the product owner and then authorised to be worked on. The idea of a scrum master authorising this work is wrong, it is not their decision, they don't own the product, and maybe the product owner will decide not to proceed with the problem features.
d) The team does not define done, and I don't understand what the phrase 'and do the same work...' means in this context, surely you don't mean that you go back to the product owner at the end of the sprint and say 'we can't demonstrate a single user story but here is some half done infrastructure and tools', that would be my idea of a nightmare.
e) The teams tools, infrastucture and skills will undoubtably improve over time, natural really, but again I rest on these things not being deliverables to the product owner, nor is it up to the team to define done. If it was I would define 'done' as a flow chart and that would be that I could go home at 10:30 on the first day of the sprint, put my feet up and drink beer for the rest of the sprint.
Am I being just a little too argumentative here?
To me scrum is about delivering what you agree to deliver, if you have any problems in doing that then informing the product owner and making a decision with them about dealing with the problem is the only acceptable outcome (and this better not happen often!).
Dave
I agree that the answers are the "least incorrect" ones. However, the Team can't have a common definition of "done" for all Backlog Items - there are too many different kinds. There are Items about product, items about improving infrastructure and tools, and others. The first two are even referenced in the question itself.
I think that the better 3rd answer is something like "Have the Team negotiate "done" with the Product Owner for each Backlog Item and ..."
Dan Rawsthorne
1) question is unclear.. does ANY in this case mean ALL as in NONE of the items can be completely finished, or does it mean that SOME of the items cannot be completely finished. Those are pretty different things and the answers may reflect that.
2) the team redefines done? eh? isn't done defined by the customer/PO/Acceptance tests? How can the team re-define that? Or is this an implication that some of the items can be partially completed and still deliver value to the customer. In that case I'd think it's time to work with the PO and the team to divide those items into smaller parts, (think of it a bit like applying SoC or SRP to the user stories) but I don't see an answer that reflects that.
3) answer #5 is obviously correct but that doesn't get us to a point of completing the sprint if a large number of the items cannot be completed. It seems like it's time to idenfity what technical investments will enable which work to be completed, scope those investments, End your current sprint, and create a new sprint that involves a combination of the smaller (more atomic) items you've determined you can do, plus specific investments in your tools and infrastructure along with completeing the items that are enabled by those particular investments.
Chuck van der Linden
I ended up with the right answers but not liking it very much because although #4 was obvious to me, #2 and #3 are NOT very clear to me at all. I really wanted to choose all three of 2, 3 and 4, except even then the same parts of 2 and 3 are not very clear to me.
#3 does not make it clear to me what is meant by "and do the 'same work' for all PBIs". What does the "same work" mean?? Is it "same process"? same quality-level (e.g., same definition of "done" from sprint to sprint?).
#2 on the other hand does not make it at all clear to me whether it means that the time does nothing but tools+infrastructure work during those sprints, or whether some PBIs can also get worked on during those sprints. Apparently the intended meaning was that it was strictly an all-or-nothing deal (very black and white).
Even knowing that still doesn't make it clear to me whether or not #3 is using a similar all-or-nothing meaning of "same work" or an "unchangeable" definition of done each iteration.
Brad Appleton
This thread has been locked.
Multiple choice ... select two
18% Asks the Team do the best it can on each Product Backlog item it selects.
6% Declares the Team not ready for Scrum.
50% Asks the Team to spend as many Sprints as necessary to prepare the engineering tools and infrastructure so any Product Backlog item it selects is potentially shippable at Sprint end.
35% x Has the Team define "done" and do the same work for all Product Backlog items it selects.
76% x Have the Team improve its skills, tools and infrastructure over time and adjust the definition of “done”; accordingly.