Change the Scrum Guide™
What is Scrum?
Definition of Done
Scrum and Agile Webcasts
Professional Scrum Foundations™
PSF Subject Areas
Professional Scrum Master™
PSM Subject Areas
Professional Scrum Product Owner™
PSPO Subject Areas
Professional Scrum Developer™
PSD Subject Areas
Scrum Open Assessment
Developer Open Assessment
Professional Scrum Master™ Assessments
PSM I Assessment
PSM II Assessment
Professional Scrum Product Owner™ Assessments
PSPO I Assessment
PSPO II Assessment
Professional Scrum Developer™ Assessments
PSD I Assessment
Work With Us
By posting to our forums you are agreeing to the
Dev Envirnoment Issues and Performance Testing
Last Post 28 Oct 2013 07:58 AM by Prabhu Missier. 3 Replies.
Most Recent First
You are not authorized to post a reply.
17 Oct 2013 09: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?
17 Oct 2013 10: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.
17 Oct 2013 10: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.
28 Oct 2013 07: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.