Moving to weekly releases

Home Forums Software Testing Discussions Moving to weekly releases

Viewing 5 posts - 31 through 35 (of 35 total)
  • Author
    Posts
  • #1121
    Anonymous
    Inactive

    Hey Dan,

    firstly, thanks for the kind words and comments and glad I can provide you with confirmation bias 🙂

    Question: “I’d like to echo a sentiment above and ask how you decided a 1 week iteration was suitable for you and what pros and cons you’ve felt this brings. We work on a 2 week cycle and I think this is a pretty widely used sprint length for normal (there’s such a thing?) projects. Also, what happens to larger complexity stories that may take over a week? Do you try and break them down further?

    Answer: Our teams work in a variety of ways, some with one week sprints and some with two weeks. Our release cycle is detached from the agile process somewhat. We decided on weekly releases because it felt right for our business, our technology and our service. Frankly moving to daily releases was probably a step too far to imagine so we picked a goal that we could realistically see in our heads and we set off on a journey to get there.
    For features that take more than a week we use various feature toggle approaches so they are turned off in production. Ideally though we try to break stories down to as small as realistic warrants the effort. Sometimes a story that is too small has had more work in defining it than in building it.

    Cheers
    Rob

    #1122
    Anonymous
    Inactive

    Hi Rainer,

    Thanks for the kind words.

    Question: Which tool did you use to draw the pie diagramm? Looks like it was drawn with a real pencil
    and scanned on a scanner, but I guess that’s wrong. Which was the book again you recommended
    during the presentation?

    Answer : The tool used to draw the pie chart was Adobe Ideas on the iPad – awesome for generating vector images for further processing.
    And the book was Elisabeth Hendrickson’s Explore It – http://pragprog.com/book/ehxta/explore-it

    Cheers
    Rob

    #1124
    Anonymous
    Inactive

    Hi Luis,

    Thanks for the kind words.

    Questions:I wan’t to know more about acceptence/UAT process:
    1) Is it done by end users?
    2) have you ever experienced it with independent testing teams?
    How does it “affect” your cycle? Can you share your share the major “dos” and “don’t dos” of it?

    Answer:
    Sometimes our customers are wanting to use new features and offer feedback so this is basically how we do UAT. We don’t call it UAT and we don’t have a special phase for UAT.
    We never use independent test teams. It’s not something we’ve entertained.
    Our release cycle continues, but we can do clever things in the product to allow certain beta users to see specific parts of the new features, like feature toggles.

    Thanks
    Rob

    #1125
    Anonymous
    Inactive

    Hi Nicola,

    Indeed. World domination will only be a few sprints away.

    Rob

    #1143
    Anonymous
    Inactive

    Hi Martin,

    Thanks for taking the time to ask a the question:
    “Lets take a tricky case that we have a complicated functionality. For example a workflow fthat starts with creating a document followed by a number of steps up to finalization. Analyzing that kind of process takes time as well developing and testing it. Any tips or tricks for that kind of situation? Cuz even if we assume that we already have the input for analysis and its with decent quality – building it all together takes time”

    Answer:
    We’d start by trying to create a vertical spike. This basically means that we would write the smallest bit of the feature we could to work all the way from the UI to the database. In this example we’d probably create a story that said we could submit a very basic form with maybe on field on it and have that register in the DB.
    We would then work our way outwards maybe building out the workflow or the form content itself or some of the validation.
    The trick is to work out what the Minimum Viable Product us and get to that point as quickly as possible. This can then be used to gather feedback to improve it and then extend it in the right direction.
    There isn’t really hard and fast rules for any of this, but I’d be tempted to create the smallest vertical (vertical through your product stack) spike of work you can and make sure you test it knowing it’s not complete. Then build out to meet the requirements you have for it.

    Hope that helps.

    Thanks
    Rob

Viewing 5 posts - 31 through 35 (of 35 total)
  • You must be logged in to reply to this topic.