Hi Thomas, all, to stress your words: I think best practice for doing usability work in an Agile Context is to extent the current sprint in both directions. Not only the next sprint needs to be prepared, also the results of the last sprint need to be evaluated in order to foster the idea of continuous improvement of the team and the results.
So absolutely agreeing with what you suggest Thomas, I would like to bring in the idea of even doing the same thing for the smaller sprints on our way to the next major release. Let's get in touch with our users - try to understand what is working good and where improvements are needed, as part of the preparation of the next sprint. And after the sprint, let's again talk to them and see if we managed to substantially improve the perceived quality. We would probably need dot releases after each sprint (and hence have a shippable product after each sprint) and we would need to implement some way of talking to the users (best would probably be directly through the product). This would also allow us to ask relevant questions on our way to a task centric approach. What do you guys think? Cheers, Björn Am Freitag, 26. Oktober 2012, 13:21:49 schrieb Thomas Pfeiffer: > Hey folks, > I have a suggestion: > I fully support Aaron's idea of small concentrated effort sprints with > integrated design and development, which comes pretty close to agile > development. However, product managers in the industry have found that such > short design cycles do not work well for all kinds of design. They work > well for small features/improvements, but for introducing larger changes or > completely new concepts, longer research/strategy/design phases work > better. > One of these big changes for me is fleshing out the general concept of > task-driven design for PA. Since the big picture won't be implemented in PA4 > anyway (we already got our hands full with small improvements/polish), I > think it would make sense to use this release cycle to work design- wise on > the big picture of a task-driven system parallel to designing the detailed > improvements for PA4 in each focus sprint. > The big disadvantage is of course that design capacity is split between the > two, but i think this is pretty much unavoidable since designing for a new > metaphor requires more then just a few weeks and we probably don't want to > have a full release without any actual development. In case of insufficient > design capacity for both, the focus sprints would always have higher > priority, of course. The biggest advantage to me is that ideally we have a > broad concept for task-driven design ready by the end of the PA4 cycle and > can implement the details for PA5 if we wish to do so. > So what do you guys think? Is the path to task-driven design worth putting > some effort into it ahead of time? > > Cheers, > Thomas -- Dipl.-Psych. Björn Balazs Business Management & Research T +49 30 6098548-21 | M +49 179 4541949 User Prompt GmbH | Psychologic IT Expertise Grünberger Str. 49, 10245 Berlin | www.user-prompt.com HRB 142277 | AG Berlin Charlottenburg | Geschäftsführer Björn Balazs _______________________________________________ Active mailing list [email protected] https://mail.kde.org/mailman/listinfo/active
