Forums

By posting to our forums you are agreeing to the Forum terms of use.
Does scrum require retrospective and sprint burndown?
Last Post 09 Jan 2014 12:36 PM by michael. 14 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Not Resolved
Reni
New Member
New Member
Posts:2
Reni

--
02 Jan 2014 08:21 AM
    Hi,

    I'm new to this forum, and obviously have a question while preparing for PSPO1: I stumbled upon the question:

    Which of the following is required by Scrum?
    A) Sprint Retrospective
    B) Members must stand up at the Daily Scrum
    C) Sprint Burndown Chart
    D) Release Planning
    E) All of the above

    So, my assumption is, that answer B is correct, as I read it already.
    What I'd like to know: Is sprint retrospective AND sprint burndown chart really strictly required? I always thought it is a recommentation to have one, but no strict rule, is my assumption correct?
    Not sure if answer D is correct, I thought we always talk about PB and SB, but not about release plan, or did I misinterpret it?

    I hope you can help? Thanks in advance.
    Cheers
    Reni
    Siva
    New Member
    New Member
    Posts:1
    Siva

    --
    02 Jan 2014 09:02 AM
    Absolutely.
    Retrospective is required for lesson learnt and do better in next sprint.
    Burndown chart is required for tracking how much time left for the sprint completion.
    Ofcourse, without a release planning - you can't have a sprint planning.
    So Ans is E.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    02 Jan 2014 09:32 AM
    A) Sprint Retrospective

    A Sprint Retrospective is a Scrum Event and as such it is mandatory, not optional.

    B) Members must stand up at the Daily Scrum

    Should, not must. Some people may not be able to stand up.

    C) Sprint Burndown Chart

    Scrum mandates that at any given point during a Sprint the work remaining in the Sprint Backlog can be summed and progress towards the Sprint Goal tracked. However, this tracking does not necessarily have to be in the form of a Sprint Burndown Chart. It could be a Sprint Burnup Chart, or a Cumulative Flow Diagram, a spreadsheet, or some other view.

    D) Release Planning

    Each increment must be potentially releasable, but this does not imply that Release Planning must occur. Release management can be done on an on-demand basis. There is no Release Planning event in Scrum.

    Olivier Ledru
    New Member
    New Member
    Posts:31
    Olivier Ledru

    --
    02 Jan 2014 09:53 AM
    "A" is required.
    "B", "C" and "D" are good practices but not required
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    02 Jan 2014 10:21 AM
    > "B", "C" and "D" are good practices but not required

    Release Planning is (arguably) an anti-pattern and not a good practice to encourage. It may be criticized for codifying the predictive planning of batches of work for future release, which is a non-agile approach to delivery. This is essentially why it was removed from the Scrum Guide in 2011. See here for more details:

    https://www.scrum.org/About/All-Articles/articleType/ArticleView/articleId/17/Gone-are-Release-Planning-and-the-Release-Burndown

    Fredrik Vestin
    New Member
    New Member
    Posts:61
    Fredrik Vestin

    --
    03 Jan 2014 03:33 AM
    Ian, I cannot agree that release planning is an anti-pattern and I don't believe that is what the article is saying. The point is that it is perfectly OK do to scrum without it which is the reason why it was removed. Same thing with burndowns, they can still be very useful but you can do Scrum without them.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    03 Jan 2014 04:39 AM
    > Ian, I cannot agree that release planning is an anti-pattern and I don't believe that is what the article is saying

    Well, I did say that it was arguable. Release Planning is a contentious issue, perhaps one of the most significant and divisive matters to affect the agile community today. Much of the brouhaha around SAFe concerns release planning and what it means for batch prediction and organizational accountability.

    The scrum.org article couches its language carefully. As such it does not go so far as to *expressly* condemn release planning as an anti-pattern. The statement "Unfortunately, some organizations use releases to compensate for bad development practices" may lend support to the case for it being so, but it would be unfair to generalise an anti-pattern from a problem that is observed to be one of exception.

    Even so, I'd assert that an implication can be parsed. The comment "Not needing release planning may actually be a positive indicator of a product’s health" is a wry one and which, at the very least, invites debate. I would therefore defend the assertion that "release planning is an anti-pattern" in so far as it seems to be a credible hypothesis, and one with significant and urgent implications for release management.
    Fredrik Vestin
    New Member
    New Member
    Posts:61
    Fredrik Vestin

    --
    03 Jan 2014 08:32 AM
    If the output of release planning is a commitment of what will be delivered in 6-12 months, then I agree it is being misused. If it is used to inform stakeholders of what is currently known about the upcoming release then I definitely see a lot of benefits and the release plan should be continuously updated.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    04 Jan 2014 12:58 AM
    I'd agree that a rolling release plan is a practical compromise, as long as it is constrained to a window of no more than six months. It strikes a good balance between the stakeholder desire for predictive information and the agile delivery of value with minimal cost of delay.

    The issue is...practical or not...it's still a compromise. Agile planning is compromised whenever you try to forecast batches of more than one sprint's worth of work. The burndown of a sized and summed product backlog can be modeled and associated projections can be made, but in an agile way of working the content of releases beyond the current sprint should not be anticipated. The inspect-adapt loop isn't tight enough to support it, and as such it amounts to unhealthy speculation.

    That's why the article cites the absence of release planning as a likely indicator of product health, and it's why the use of release planning can - arguably - be seen as an anti-pattern.
    Reni
    New Member
    New Member
    Posts:2
    Reni

    --
    09 Jan 2014 06:33 AM
    Hey,
    thank you all!
    The variety of answers shows that SCRUM is somehow really a matter of interpretation. I know it should not - but it obviously is. However, based on all answers you gave I would chose answer A and B.

    @ Ian: for answer B: unfortunately the text is "B) Members <b>must</b> stand up at the Daily Scrum" I guess that it is clear that anybody who is not able to do so (because of a disease or sth. similar) can remain seated... so I would chose B nevertheless, what do you think?

    Again, thank you for your help.
    fvt
    New Member
    New Member
    Posts:5
    fvt

    --
    09 Jan 2014 07:17 AM
    I would go with this answer, since
    "A" is a scrum event

    "B" is not mentioned in the original scrum guide as far as I can read a few minutes ago (I know it is also called Standup, but it is not written in the guide). Please correct me if otherwise stated.

    Best
    Frank



    Posted By Olivier Ledru on 02 Jan 2014 10:53 AM
    "A" is required.
    "B", "C" and "D" are good practices but not required

    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    09 Jan 2014 08:36 AM
    > I guess that it is clear that anybody who is not
    > able to do so (because of a disease or sth.
    > similar) can remain seated... so I would chose
    > B nevertheless, what do you think? 

    It may be clear to us that people who can't stand aren't expected to, but the question doesn't provide for that assumption. It says must, not should.

    Also we should bear in mind that the term used for the event is, strictly speaking, a Daily Scrum and not a Daily Standup. This in itself suggests that standing up is not mandatory.

    So although the situation with regard to B is not entirely clear-cut, I think the weight of evidence is against choosing it.
    Nitin Khanna
    New Member
    New Member
    Posts:47
    Nitin Khanna

    --
    09 Jan 2014 09:54 AM
    Although, a little late, allow me to share some of my understanding...

    The correct answer is "A" and is clearly written in the scrum Guide.

    "B" is misleading and incorrect. I would like to throw in where this may have stemmed from --
    http://www.extremeprogramming.org/r...eting.html

    i.e. for those familiar with eXtreme Programming (XP), standing up in close proximity is encouraged for the daily meet and the norm. Remember -- the assessments at Scrum.Org are focused on Core Scrum, and not really on other Agile practices.

    If a Scrum Team decides they want to all stand up every day during this event, they certainly can. However, this is not mandatory and this may not be as useful for Teams not co-located.
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    09 Jan 2014 10:36 AM
    As Nitin says, it isn't core Scrum. It's more of a cultural practice. For the reasons behind it see:

    http://martinfowler.com/articles/it...ml#StandUp


    michael
    New Member
    New Member
    Posts:30
    michael

    --
    09 Jan 2014 12:36 PM
    The wording is bang on its how the jedi mind trick is interpreted as quite rightly some are good practices.

    Required
    "officially compulsory, or otherwise considered essential; indispensable"
    How would this now affect your approach to the answer to the question?

    Didn't give the answer away :-)

    Michael

    You are not authorized to post a reply.


    Feedback