Dev Team Hours

Scott,

please don't expect from Scrum Guide to give you direct answers to all the questions.
You have to remember that Scrum Guide is the tangible implementation of the Values and Principles of Agile Manifesto for Software Development. And one of those principles talks about "sustainable pace". That's the speed of development that the Development Team is capable to keep indefinitely long.

Also the foundation of the Scrum are the 5 Scrum Values (Openness, Commitment, Focus, Respect, Courage).
Please keep that in mind too when answering any question.

A team following Scrum will provide regular incremental deliveries of value. The only measure of success is whether or not such deliveries are made. The number of hours that have been worked is not a substitute for such value.

So of the three answers you can remember, it seems that you can eliminate the first (ideal hours) and the last (7-8 hours per day). They may be good answers, but they are not the best. The middle answer (enough to meet their commitments) appears to be the better one. A Scrum Development Team will commit to achieving a Sprint Goal and the Sprint Backlog that they have forecast for delivery. It is up to that team how many hours will be worked to achieve that goal, and who will work them and when in the Sprint. As long as the Product Owner is satisfied with the delivery it is immaterial how the team self-organized their working time in order to provide it.

Ian, I have to disagree with you

The key to the correct answer is the "sustainable pace".
Working 7-8 hours per day - IS sustainable pace.
I want to give a quote from Ken's book "The enterprise and Scrum":

The product that was developed using Scrum was Vosod. It began to emerge in high-quality, regular increments. Joris adopted a sustainable pace of work, one of Scrum's practices. Everyone worked eight-hour days. Some people might look at that practice and think, "Oh, that means developers get out of working hard for the company!" Quite the contrary—a sustainable pace yields higher productivity and quality products.
Adventure Works was owned by a Japanese company. The Scrum practice of eight-hour workdays was unacceptable to the senior members of the Japanese management. They demanded longer hours, and the 12-hour work days that were normal prior to Scrum were restored.

So as you see it's all about regular hours of work per day.
To work "enough to meet commitments " does not guarantee you a sustainable pace at all.

I agree 100% with Illya.

As a team matures their understanding of how much they can commit to will evolve and become more predictable. Adding extra hours to compensate for over-commitment sounds like the bad old days of waterfall where someone else made the commitment for the team!

If the team over-commits then you'd be looking at a scenario where it takes 18hr days and a hero culture to meet the commitments. That's not sustainable (or healthy).

Of course, if a team under-commits, they can conversely "get away" with working fewer hours to deliver on their commitments, but that's equally unsustainable.

> Ian, I have to disagree with you
>
> The key to the correct answer is the "sustainable pace".
> Working 7-8 hours per day - IS sustainable pace.
> I want to give a quote from Ken's book "The enterprise and Scrum"...

7 - 8 hours per day may not be sustainable for some team members. It's up to the team to decide how many hours they can work and they should reflect that decision in their Sprint commitments.

There's another clue here. Given that Scrum is a framework and not a methodology, it's very unlikely that Scrum would prescribe "ideal hours" or indeed a specific number of hours. This stands in contrast with other agile approaches such as Extreme Programming (XP). If I recall correctly, in XP a 40 hour work week is a key practice, but that's the sort of prescription that makes XP more of a methodology than a framework.

Now, if this question had related to the PSD certification I think the correct answer would be less clear, given that PSD seems to be founded on many XP practices including refactoring, TDD, and (possibly) a 40 hour week.

> Given that Scrum is a framework and not a methodology, it's very unlikely
> that Scrum would prescribe "ideal hours" or indeed a specific number of hours

I should be more precise: a working day is not a time-boxed event in Scrum

I think "sustainable 7-8 hours" is a trick answer. I also think that this question and many other questions, we could write why we chose one answer over the other(s). My answer would be: as much as needed to complete the forecast with openness. i.e. let the PO know it is taking longer and the reason (be it lack of experience, or it is really more work now that we know more on Nth day of the sprint). So PO knows the team is committed. Eventually, the team should reach to a level where they can accurately forecast and complete the work by working at sustainable pace. Yes, "sustainable" is a relative term (for example, some team might work more MON-THU and 1/2 day on FRI which is perfectly fine, and some company culture is just that!)

The new Scrum Guide says the development team only forecasts stories they will have done at the end of the sprint.
There is no comitment anymore so i'm with Illya 7-8 hours

Hi,

I was in the same position by 1% so really know where you are coming from when you get one like this.
This is where PSM1 really falls down , Ken says the SCRUM guide is enough to pass the exam.
https://www.scrum.org/Forums/aft/553

Feedback as you have gathered from the fail has now left you not knowing what the actual answer is and is being debated in this forum, so do think that PSM1 is a little unkind in many aspects.
I would have gone with 7 hours as that i too think that it is a sustainable pace, but SCRUM does not assign a timebox on this, so my guess could be wrong.
The best bet is mail Ken or Jeff as they would be the experts, and as its costing you 100$ you do want the correct answer to give you the best chance of passing on your resit.

> I would have gone with 7 hours as that i too think that it is a
> sustainable pace, but SCRUM does not assign a timebox on this,
> so my guess could be wrong. 

I think that's the correct analysis, even if the correct answer remains dubious.

If the right answer turns out to be a certain number of hours the repercussions would be significant, given that a working day is not a time-boxed event in Scrum. I suggest that it is wisest to apply the principle of least surprise.

I took the PSM level 1 test today and this question came up. I passed with 72/80 so I don't know if I got this question correct or not, but I went with the answer "At a sustainable pace, usually 7-8 hours per day".

Scrum does not assign a time box for dev team hours, but then "usually 7-8 hours" is not a fixed, proscribed time box in the same way that "daily stand ups are 15 minutes" is. The key phrase for me in the answer is "sustainable pace". The dev team need to work at a sustainable pace so that there is a "constant" against which the team can demonstrate accuracy of estimation, whether they are taking on too much, too little and so on.

It's ironic given the ethos of Agile is one of continuous improvement that the feedback from the exam does not show you what questions you got wrong and direct you to appropriate resources. So I don't know if I got this specific question right or wrong, but I stand by my logic in how I answered it.

From Kanban.. Capacity limits, limiting the hours to prevent wastage caused by overburden. 7-8 hours is sustainable, 99% of people work within that capacity and the team should self manage to sustain a pace that doesn't cause burn out, if they're finding they have to work additional hours to meet sprint goals, then they should readdress the work taken on In the sprint review and adapt it in sprint planning and then to take on enough work to deliver a shippable item without overburden.
Overburden causes waste and decreases quality, work capacity should be inspected and visible , midnight warriors are all too common but aren't part of a well structured team..
Waterfall models should be all the evidence you need, badly forecasted work and then you're sitting with your team till 3am to get work done in time for a milestone..

The same question appeared today in my exam, which I failed at 83.8%, so I am joining the club of those who failed at one wrong answer too many! I answered 7-8 hours or a sustainable rate to this question, but it seems I will never find out if that answer has cost me another $100!

Sounds tough and scary as I prepare for my PSM I exam.

I would have picked "enough to meet their commitments" out of the 3 choices of: ideal hours, enough to meet their commitments, and 7-8 hours per day, figuring that if they over-committed, they could either work a little longer this Sprint or re-negotiate with the PO.

However, if one of the choices was "At a sustainable pace, usually 7-8 hours per day," I would have picked this one as "At a sustainable pace..." is the key phrase for me (and a few others here that mentioned it).

Hmm, learning for PSM1 I'm also looking at this :)

I would think 'enough to meet commitments' can easily be scrapped, it's against Scrum in most ways :)
- Not Transparent, it's hard to establish a baseline if overcommitments are hidden by working more.
- Not good for the Team (rushing = lower quality, productivity, creativity).
- Scrum Guide itself says that in case of overcommitment you re-negotiate scope (between dev./PO).

The other answers are harder, but since their from memory it depends how the original exact phrasing was :)
Some thoughts:
- I think it should at least be stable, Transparency again.
- But, anything mentioning a specific length is dubious to me, this may depend on culture (country dependent?). But maybe 7-8 is the norm worldwide, so I'm not sure :)
- 'Ideal' is also suspicious, Ideal to me would be stable, long enough to get work done productively, without impacting the team in a way that would reduce creativity, productivity, etc. :) ). But ideal is rather open to interpretation isn't it? :)

I'd love feedback on my interpretation ;)

I would support "Ideal hours". The reason are:
1. The team should work only ideal hours in a day.
2. Time is spent in meetings and other coordination. We do not know what this can be.
3. If we are spending "enough to meet their commitments" then we may look at working 20 hrs a day and try to complete the work. Which is against the principle of Agile. Bad option
4. "7-8 hours per day" is also bad as you are not leaving time for scrum meeting and other coordination/clarification

Please let me know what you think.

Honestly, I find it a bit disturbing that even the experts are confused by this question and that such subjective and vague questions are included in the exam. It seems like it doesn't matter how much you study and how many years you practice Scrum, your answer will still be a guess. I bet if we polled the official trainers conducting the scrum.org training courses we'd get just as many differing opinions on this.

Dear scrum.org, that's just not right. Please practice transparency. How can we get this resolved?

Hello Alan (et. al.),

We sincerely appreciate all of the great feedback and discussion on this thread!

Alan, in kind response to your call for action:

Transparency:

In the spirit of continuous improvement, we regularly refine our assessment questions through incrementally inspecting and adapting. When doing so, we take well-thought-out feedback like this into consideration. On that note, we agree that some room for possible ambiguity exists within this specific question.

Resolution (and more Transparency):

In response, we removed this question from our available question banks during one of our recent refinement sessions. The question referenced in this thread is not active and no longer appears in any Scrum.org assessments.

Thanks again to all for the great interest and feedback.

Enjoy your day!

---Joe

Great news! Thanks for working this out, Joe!