Scrum guide interpretation

Work can be completed and demonstrated to the Product Owner at any point during the Sprint. It is not necessary to wait until the Review. Such collaboration on an ongoing basis can help to de-risk delivery.

Thanks Ian. No good deed goes unpunished, so here's another 3 for your troubles:

(1) Only dev team or dev org defines ‘DoD’ is how I read the Guide. Why should POs have no say?

(2) "Sprints best have consistent duration...", This suggests that there are circumstances where it is OK for them to have varying lengths - when it might be OK and how would such a decision be made?

(3) "Scrum master enforces rule that only Dev team participate in daily scrum". I understood that they can invite others (eg PO) to observe. Surely the Dev team can chose to invite others to comment?

The sentence is under a subscetion of "Product Backlog" so you can read this as "The PO should track total work remaining within the Product Backlog "
Sprint by Sprint and increment by increment this can be updated.

Cheers Benjamin

Hello
I would say that there is no request to review sprint backlog by PO. It is enough to review PB. Anything not finished during the sprint is moved back there anyway.
On the other hand "monitoring" during the sprint may not have much sense. Team delivers and is responsible, what will be delivered is known when sprint is finished. "monitoring" seems mixing e.g. waterfall with scrum.
Dev team do not remove rather the PB backlog items - its PO work. Other wise it a mass, The best is one dedicated person and the PO is the right one.
Cheers,
Rom

Paul,

Regarding your inquiries:

(1) The team is best suited to determine the criteria for their Definition of Done (DoD), but this should be arrived at through discussion and consent with the PO. There may be DoD criteria desirable by the PO, but not possible at that time either due to organizational or technical constraints. The PO needs to be made aware of what is possible, and what may be possible in the future. Transparency is key here.

(2) Indeed, the best sprints have a consistent duration for the team / development effort. What the Scrum Guide doesn't explicitly state, but which I will, is that it is a very poor approach to vary sprint length. I can see new teams possibly doing it, in order to settle on a sprint length that works best for all involved. However, the goal should always be to settle on one sprint length, and then stick with it.

Changing sprint lengths distort a team's ability to determine their velocity, and drastically increases the complexity around planning for an organization. You simply cannot develop a consistent "heartbeat", along with the predictability inherent with that heartbeat, if the sprint length changes.

There are benefits and downsides to every sprint length (1, 2, 3, or 4 weeks), but the typical "sweet spot" is a 2-week sprint duration.

(3) The Daily Scrum is intended solely for the team's benefit, to allow them to touch base and get on the same page regarding sprint progress and issues. Others may attend in the spirit of openness and transparency, but should only be allowed to listen in on the team's discussion, never to participate.

The goal of the Daily Scrum is to complete it within a 15-minute time frame. That becomes very difficult if others outside the team are allowed to participate. That is not to say that these conversations/inquiries don't have value, or should not take place. It is just that they cannot occur during the Daily Scrum. It is a team-only meeting.

Timothy,

I has a lengthy discussion recently with my brother about the question of varying the length of Sprints, and so far we disagreed.

My brother's opinion is similar to yours, i.e. equal length, providing heartbeat to the process, and the arguments for it are quite good.

However, in many situations that ideal is not attainable, and not for the lack of commitment or experience on the part of the team. One example I came across was a situation where the company (non-IT, actually a financial institution) had stringent rules on releases, change management and pre-release testing. Regardless of development processes, both internal procedures and regulatory requirements mandated a nearly 2-weekly process before a major release (and sneaking repeated minor releases was a no-go). Although the team in question wasn't using Scrum at the time, I have been using them as a mental case study to try to fit Scrum on top of the situation and see how it could work.

Saying that in this case Scrum was not a good choice is a cop-out, as it would be just admitting that dogma is more important that adaptation. So, I believe that, in such a situation, having 30-day development Sprints, occasionally interspersed with 2-week release-dedicated Sprints, could be a solution. (BTW, a 2-week fixed duration might have been a solution, but 30-day for development would probably have fitted better, since this was roughly the commit-review cycle we had anyway, even without Scrum).

> (1) Only dev team or dev org defines ‘DoD’ is
> how I read the Guide. Why should POs have no say?

The PO may well have a say, and can be consulted, but he or she is not in a position to actually define it. The DoD is a technical assertion of quality which developers must observe, and it is therefore the responsibility of developers to assert its terms.

> (2) "Sprints best have consistent duration...",
> This suggests that there are circumstances
> where it is OK for them to have varying
> lengths - when it might be OK and how would
> such a decision be made?

If, during a Sprint Retrospective, it is determined that better value can be delivered by adjusting Sprint length then the Scrum Team may adjust it accordingly. The key driver to defining Sprint length is the optimal delivery of business value as defined by the PO.

> (3) "Scrum master enforces rule that only Dev
> team participate in daily scrum". I understood
> that they can invite others (eg PO) to observe.
> Surely the Dev team can chose to invite
> others to comment?

Look at it this way: surely the Dev Team can self-organize a more appropriate time for these discussions? The Daily Scrum is *their* opportunity to replan *their* work so the Sprint Goal can be met. It might be the only opportunity they have to do so in a busy working day.

Posted By Artur Guja on 14 Oct 2015 06:02 PM

equal sprint length, providing heartbeat to the process, and the arguments for it are quite good.

However, in many situations that ideal is not attainable

Artur, I would disagree with your assertion that there are many situations where sprints of equal length are not attainable. The evidence simply shows that most companies practicing Scrum (either effectively or ineffectively) do so with sprints of equal length.

Posted By Artur Guja on 14 Oct 2015 06:02 PM

having 30-day development Sprints, occasionally interspersed with 2-week release-dedicated Sprints, could be a solution

What you have explained here is a situation where there are several 30-day sprints, followed by a 2-week "period" devoted to release and hardening activities. This 2-week period is not a sprint, as it is dedicated to change management, testing, and release tasks and meetings, and does not involve the Scrum team in producing anything new of business value.

The Scrum Guide provides the following definition of a Sprint: "The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created... Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective... Like projects, Sprints are used to accomplish something... Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product."

In your example, the sprints are 30-days, interspersed with a 2-week "break" from sprint activities, and not an example of varying sprint lengths.

I would even go so far as to note the organizational impediment in your example (requirement for a 2-week period to prepare work product for production), and question whether your 30-day work periods are even "sprints", since the resultant work product is apparently not in a releasable state.

I would even go so far as to note the organizational impediment in your example (requirement for a 2-week period to prepare work product for production), and question whether your 30-day work periods are even "sprints", since the resultant work product is apparently not in a releasable state.

This, to me, is the single biggest difference between Scrum and life, at least in my experience: Scrum seems to assume that a "release" entails zero work and happens magically between a Sprint Review and the next Sprint's Planning, when someone presses a "release" button and it's done. In reality, release takes time, so either we include release activities in the next Sprint or, if they are chunky, devote the next Sprint to the release and get it out of the way before getting back to working on the PB proper.

Furthermore, there seems to be an inherent fallacy or loop if a Sprint is not allowed to include release activity. Done items from the Sprint are accepted by PO during the Sprint Review. Then, PO may decide to release the "done" work. So, when is it released, if not during the next Sprint?

I've worked only briefly in an IT-centric organization, and indeed a "release" could be then accommodated in a Scrum-friendly fashion (within the finalization of a Sprint). However, since then I've worked for financial institutions, and some of them had Scrum-like methodologies, and since then many adopted Scrum (in various forms). However, the reality then is that a release is a lengthy process. And it's not correct, I believe, to say that such a process is an impediment, as that would imply it can be removed.

This is, in my opinion, fully reconcilable with the philosophy of Scrum, if only the understanding of "releasable" is modified just slightly. A "development Sprint" provides releasable functionality in the sense that it completes fully items of the Product Backlog (fully within the DoD), and the functionality is "released" to the product. A "release Sprint" also delivers functionality in that it actually delivers the previous Sprint's increment to the users (isn't that useful?). Due to every development Sprint being releasable, a "release Sprint" can be called at any point between "development Sprints", as needed by PO.

> ...in my experience: Scrum seems to assume
> that a "release" entails zero work and
> happens magically between a Sprint Review
> and the next Sprint's Planning

In my experience it's organizations which tend to assume this fallacy. In Scrum it is made clear that each Sprint *must* include all of the work needed to make an Increment potentially and immediately releasable, including integration and testing. If a team's Definition of Done doesn't include *all* of the work necessary for a potentially immediate release then the DoD needs improving. If the team or organization can't support a better DoD then their practices and behaviors are in need of improvement.

> ...a "release Sprint" can be called at any point
> between "development Sprints", as needed by PO.

Any Sprint that is not intended to deliver work of release quality isn't a Sprint at all. It's more of a "scrumble", something which Ken Schwaber recently talked about on his blog:

http://kenschwaber.wordpress.com/2015/09/28/scaling-the-nexus-and-scrum…

> It's more of a "scrumble"

Correction: I should have said it's more of a scrumble situation. If Sprints are inadequate, and are not delivering fully integrated work of release quality, then a scrumble may be necessary to close the gap and pay off the incurred technical debt.

Artur, I'm glad that you prefaced your reply as it applied to your own experience. Often, we have difficulty conceiving things that are outside of our current understanding.

The reality is, there are many organizations that indeed release to production by simply "pressing a button".

And this is not limited to small companies and startups. Recently, this became possible at JP Morgan Chase:

http://www.infoq.com/articles/large-scale-scrum-jomorgan

This was a long and sometimes painful process. But it is possible. And it happened at a Financial Institution that I'm willing to guarantee is much larger and more complex than your company, unless you work at Well Fargo perhaps.