Re: Test and documentation tasks at end of iteration
- This approach goes against the idea that everything included to complete an item should be done within the sprint. code, docs, tests etc. If I disregard that rule I could just as well wait with test and documentation to the last iteration... 8-)
I don't have requirements spec. writing in the iterations either. To me that's a work for the PO when working with the product backlog and should not be in a sprint as it does not add any value to the product.
--- In email@example.com, "Kenneth Smith" <ksmith1833@...> wrote:
> Try moving your testing and documentation to iteration n+1, it's the same concept as requirements for the current iteration's development is in n-1.
> -----Original Message-----
> From: "frede_swe" <fredrik.vestin@...>
> Sender: firstname.lastname@example.org
> Date: Tue, 06 Sep 2011 19:21:28
> To: <email@example.com>
> Reply-To: firstname.lastname@example.org
> Subject: [scrumdevelopment] Test and documentation tasks at end of iteration
> Consider the following scenario.
> A PBI is added to the sprint backlog and broken down into three different tasks
> 1. Code it, assigned to developer
> 2. test it, assigned to QA-person
> 3. document it, assigned to a third person.
> The sprint progresses fine and with 2 days left of the sprint, the developer checks in the code with unit tests performed etc. Now, with 2 days left in the sprint, there's no way that the task can be tested and documented and all 3 tasks must be completed in order for the item to be done. So what do you do?
> 1. Move all tasks in the story back to backlog
> 2. Move the two remaining tasks (doc and test) to the backlog and keep the coding task in the iteration.
> or what? The developer completed all the tasks that he/she committed to in the sprint planning so the developer but the persons documenting and testing did not get a fair chance to complete their task.
> I am constantly facing this problem at the end of sprints and need ideas how to overcome this, or suggestions for a different approach.
- Capers has data that says by the 6 month mark more than 80% of the requirements change. I think this is from the _Assessments of Software Risks..._ book.JohannaOn Sep 15, 2011, at 3:14 AM, Keith Ray wrote:
Even waterfall projects that attempted to "fix" requirements had 20% of the requirements change every quarter. (Capers-Jones?)
C. Keith Ray
Amplify Your Agility
Coaching | Training | Assessment | eLearning
On Sep 14, 2011, at 11:21 PM, Michael James <mj4scrum@...> wrote:
> On Sep 12, 2011, at 7:03 AM, Lisa Sawyer wrote:
>> If I know that 85% is going to change between now and Beta, my time is better spent in other areas than to redo everything every week. If there is 15% change, then I have no problem.
> By the time a typical product is truly fit for use, nearly all of it will have been reworked at least once. I'm thinking this will only increase as users come to expect better fitting products.
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links