Forums

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Done vs. done done
Last Post 23 Jun 2014 10:57 PM by Ludwig Harsch. 6 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Pablo Rossi
Basic Member
Basic Member
Posts:181
Pablo Rossi

--
22 Jun 2014 02:03 AM
    Hi all,

    Within my current company I'm facing with the following problem.

    Our development is using scrum to deliver small stories. This is going well and we've build up a steady pace within our 2 week sprint.

    Although the development team is doing a good job in delivering stories every 2 weeks, the story is not 'done done'. After the stories are 'done', other external process (which are depending on the stories, like some hardware modification etc.) gets started.
    So, the team is able to produce stories within 2 weeks, but for it to be 'done done' we're usually talking about several months.

    What to do? (by the way including these external processes is not an option)
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1556
    Ian Mitchell

    --
    22 Jun 2014 09:58 AM
    Incremental releases can be seen as part of a value chain, where value is added by different stakeholders at different points. One team's understanding of "done" may not match that of consumers further down the chain. That doesn't necessarily mean that there is a problem and that the team's DoD is inadequate. The increment might well be fit for purpose as far as a PO is concerned. He or she might simply plan to add further value to the product in order to sell it on, this perhaps being their business model.

    The key consideration is that of technical debt. If you find that you have to perform rework as a result of the "external processes" you mention, then you do indeed have a problem, and the DoD is not fit for purpose.
    Pablo Rossi
    Basic Member
    Basic Member
    Posts:181
    Pablo Rossi

    --
    22 Jun 2014 08:41 PM
    Hi Ian,

    This is the case. Sometimes problems gets discovered during that phase which results in rework.

    Now that external (hardware) process that comes after software development is a very complex process which is almost unplannable. Only when we're in that second phase, we find out what we're missing.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1556
    Ian Mitchell

    --
    22 Jun 2014 10:20 PM
    OK. The first thing to do is to deduce (or estimate) the cost of this rework. If you have a hard figure of what this is costing the company, you are more likely to get executive sponsorship for a solution.

    The figure should include the time cost of teams performing the rework, the cost of any additional resources consumed, and the cost of delay incurred by having to revise the product before it can reach the market. Other things to factor in might include a wider missed opportunity cost (while a team is tied up doing rework, other opportunities may pass the company by) and quality cost or cost to reputation (since not all of the technical debt may be discovered during rework). These are harder to estimate.

    I recommend getting a figure like that first. Once you have it, you should effectively have a budget for working out a solution.
    Sean Byram
    New Member
    New Member
    Posts:1
    Sean Byram

    --
    23 Jun 2014 01:07 PM
    My team faces the same issue. Although for us, testing is the piece that doesn't quite fit within the two-week sprint so stories and tasks that are implemented in sprint 1, aren't testing by QA until sprint 2.

    Jaya Prakash Mudugal
    New Member
    New Member
    Posts:7
    Jaya Prakash Mudugal

    --
    23 Jun 2014 02:27 PM
    On similar lines what Ian expressed - I wanted to put my views. Please feel free to correct me

    Quite often vendors or external parties don't adopt methodologies which organisations practice .

    A working shippable product increment (definition of done) has to be determined within spring planning.
    So a risk has to be logged with PO if by any means we think definition of done will have a external dependencies.

    Also, Vendors or external parties should be made clear (with support from management) that sprint goal is important and they should show up instead of delaying the results.

    I think the best way would be to include this support role into development team so that they will have accountability / ownership for the sprint goal.

    If current sprint testing and QA is done in next sprint , it's not scrum but we can name it as ScrumBut. ScrumBut can never have desired results as Scrum.
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig  Harsch

    --
    23 Jun 2014 10:57 PM
    If I understand correctly, you are trying to scale Scrum. What you call "done done" should just be called "done". The definition of done for each team should include integration with all other teams. This means it might be impossible to have 2 week sprints, because it is not enough to deliver the stories. If hardware is included, it can even be very difficult to have 4 week sprints. If your company is fine with several months of development, and you do not need to be more agile, that's OK. You can consider the software of your team as the product which is delivered to the other teams who are stakeholders, and you can do isolated Scrum.
    However if the market and competitors force you to be faster than that, you should think about how to get to 4 week sprints with an integrated increment at the end. There are approaches for this like rapid prototyping.
    You are not authorized to post a reply.


    Feedback