All About Agile | Agile Development Made Easy!
How long do you have to release product-increment on each Sprint?
I'm wondering what your experience is on how much time is needed from code-freeze (no new stuff into the "release" of the Sprint) until the installer is ready to pass to the customer.
In my project, we code-freeze on Thursday noon. Then the "release" is built (including all automated tests; and yes we have continuous integration - o this is acctually checked before) resulting in several installers. Then we install it on the test system (where interaction with the real hardware can be checked) and run a part of our acceptance tests (automatic and manual). Our software consists of workflows that take 2 to 3 hours to complete (its not bad performance - it's the chemicals that take so long!). Finally on Friday, normally at noon, we know that we can ship.
What's your story?
In my project, we code-freeze on Thursday noon. Then the "release" is built (including all automated tests; and yes we have continuous integration - o this is acctually checked before) resulting in several installers. Then we install it on the test system (where interaction with the real hardware can be checked) and run a part of our acceptance tests (automatic and manual). Our software consists of workflows that take 2 to 3 hours to complete (its not bad performance - it's the chemicals that take so long!). Finally on Friday, normally at noon, we know that we can ship.
What's your story?
Views: 4
Replies to This Discussion
-
Permalink Reply by Robert Sfeir on -
For us there used to be such a thing as code freeze but there isn't anymore. The Sprint is done when the stories that were assigned to that sprint are written.
In general our sprints are 3-4 weeks. It depends on the total number of points assigned to the sprint. Based on our velocity I know that I can do x points per week. So we assign issues and fit them to what we know we can do. Once all stories are done, the sprint is done, and it's usually the 3 or 4th week mark. At that point we discuss with the product owner if what we have is good enough for a release, and if it is we make a build and proceed with pushing it out to production. In the mean time, we perform a retrospective to make the adjustments needed, we do our sprint pre-planning which involves looking at stories needing triage (those are stories we haven't looked at), meeting with product owner to determine story rank (what is most important at this point in time), looking at the pre existing sprint plan and modifying it to match the issues of the day, and we start a sprint meeting and go again.
Does that help?
R
-
Permalink Reply by Urs Enzler on -
Thanks for your reply. But there is sime missunderstanding.
My question is how others handle the problem that building the product increment of the current Sprint (that is passed to the customer for review) takes a lot of time. In my case this time is about 8 hours. That's time time it takes to run a complete test suite (again, this is due to the hardware).
I'm interested whether other teams have similar problems or whether most of them can integrate, build and test their product within just some minutes.
btw We like the fix Sprint length of 2 weeks because we are really in the groove of it. A flexible Sprint length isn't a solution for us.
Cheers,
Urs
-
Permalink Reply by Stavros Pitoglou on -
@Urs Enzler
Well, from your posts I can make the assumption that there is more to testing your software than merely having it tried out on a computer. You mention "chemicals", so I think that maybe there is some analytical, laboratory or industrial hardware involved. In that case, the answer lies in the possibility of performing overlapping tests during the iteration/sprint. I understand that maybe that is not possible [maybe there are costs included that prohibit more frequent tests, or maybe -like a medical laboratory software team I once managed- you cannot have all the devices in the site of development.] In that case, there is not much you can do, as you -by default- lack the necessary agility to complete the lifecycle at user story level during the sprint.
If that is not the case then consider having your user stories tested immediately after completion. Maybe you can adjust your automated tests to run for the portion you have created or updated at that time.
I don't know if this helps, as it lacks crucial information concerning what exactly you do and the way you work and organize.
Once mentioned in this thread, as far as it concerns the 'flexibility' of the iteration duration, I am a believer and follower of the strict time-boxed approach ,even if the declared sprint scope does not get achieved every single time. I believe in steady development pace, and I thing that the pace should define the result rather than vice versa. But, of course, this is always a subjective matter of opinion and approach, and it depends heavily on the particular circumstances of a given oXrganization.
-
Permalink Reply by Urs Enzler on
-
Thanks for your thoughts.
We do not have a problem with this. I stated the situation in my project as a sample of a definition of done for a single story (automatically tested as far as possible - meaning not on real devices, just in simulators). But to build the Sprint increment we need some additional manually testing to make sure that we deliver quality.
There is no need to change this, we do just fin this way.
However, I'm wondering whether we are a special case or this is just normal for most Scrum projects. So I'm interested in how other teams define done (within a Sprint) and how they make sure to have a fully functional Sprint increment. Most literature do not really provide an answer how to close this gap.
Cheers,
Urs
© 2012 Created by Kelly Waters.
