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.

Dev Envirnoment Issues and Performance Testing
Last Post 28 Oct 2013 03:58 AM by Prabhu Missier. 3 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Tom Hosiawa
New Member
New Member
Posts:1
Tom Hosiawa

--
17 Oct 2013 05:17 AM
    Hi, I have two questions in trying to apply scrum to our organization

    1. We have issues with our development and/or testing environments being down (from a few hours, to a days in two week periods ). How do you account for these in the sprint when they occur? If you lose a day of development, should you remove an item from the sprint backlog?

    2. Because multiple projects are competing for access to our performance testing environment, they must be schedule way ahead of time, meaning we can't incorporate it in our DoD definition. Any thoughts on how to best approach this?

    Thanks
    Tom
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1695
    Ian Mitchell

    --
    17 Oct 2013 06:11 AM
    1. Assuming that there is no other work on the Sprint Backlog that can be progressed, and that the Sprint Goal is likely to be affected, the Product Owner must be notified. The Sprint needs to be replanned and this could indeed mean changing the backlog. In an extreme case the PO can terminate the Sprint if the revised ROI does not justify continuing. In terms of replanning, the Scrum Team should give priority to overcoming the environmental issues since that is part of their process, and they are clearly not in control of it.

    2. You have a problem in so far as you will accumulate technical debt in relation to system performance. It also implies that each end-of-sprint increment will not be potentially releasable into live, and that ROI and further discovery will be delayed. Unfortunately, again it shows that the team are not in control of the process for creating a potentially releasable increment. This can be tackled gradually, such as through better release planning that expressly includes performance testing. Note that the Definition of Done can (and should) be improved on a Sprint by Sprint basis...an improvement that should certainly include getting work closer to live.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1695
    Ian Mitchell

    --
    17 Oct 2013 06:22 AM
    NB transparency is key in both matters. Cumulative Flow Diagrams should reveal the blockage of work due to system downtime, and its accumulation prior to entry into performance test. This information should be shared with stakeholders and influencers. They might be in a position to supply better resources if the impact of the current set-up is made clear in this way.
    Prabhu Missier
    New Member
    New Member
    Posts:26
    Prabhu Missier

    --
    28 Oct 2013 03:58 AM
    1)Looks like a candidate for a recurrent impediment. If it happens unpredictably then you would need to adjust your Sprint Backlog and Sprint goal accordingly.
    But if you can predict it then your Sprint Plan needs to handle it. If you have previous data then you might have a fair idea of the amount of work you can accomplish inspite of the impediment. That being the case your Sprint planning will have to factor in the predicted disruption and forecast a reasonable Sprint goal.

    Ofcourse it is the duty of the Scrum Master to remove impediments so he or she has to make an all out effort by even talking to C level to isolate and solve the problem.

    2)I am facing that issue right now. My Perf team has gone on vacation and there's a lot of pressure to dilute the Def of Done and not place emphasis on Perf testing.
    I for my part have said that this is unacceptable and have approached Senior Management for their help since it is quite obvious that a properly "done" story will include Perf testing as well if it is relevant at all to the story.
    You are not authorized to post a reply.


    Feedback