Loading ...
Sorry, an error occurred while loading the content.

7055Re: stories and wireframes

Expand Messages
  • Chris
    Mar 3, 2010
      Hi Tim

      benefits of an agile approach, are not obvious, if you are new to it, and it does take time to win the client/stakeholder(s) over sometimes.

      the Analysis, happens early on, this is true, but it is not shallow, if anything it is deeper than traditional approaches.

      1. Team based meetings that are designed to generate awareness of the project, as a whole.

      2. Team meetings to establish the weight of each component of the project, adds another level of project awareness through the team.

      3. Indepth consideration of each component, breaking it down into independant/dependant/critical/non-critical elements

      these 3 stages of project understanding are so beneficial, and when you involve all the people and utilise the idea of open questions, the team can get great focus and direction.

      4. Sprints, quick daily catchups, can seem daunting, commiting 20 minutes each day, but, again these are so beneficial, because indirectly each team member that is having an active part at the time in the sprint, gets direct feedback.

      in fact the only potential obstacles to an agile project work method, are the people involved. - awareness of the methodology is best gained through taking the plunge and trying it. We got an external agency in to train up the scrum masters.

      Good times


      --- In agile-usability@yahoogroups.com, Tim Wright <sambo.shacklock@...> wrote:
      > Here's a question that's been in the back of my mind for some time now:
      > If the only up front analysis work you do is enough stories for the first
      > iteration, how do you estimate the cost of the project so that the sponser
      > can determine if the project has a worthwhile cost/benefit ratio?
      > Tim
      > On Sat, Feb 27, 2010 at 7:07 AM, William Pietri <william@...> wrote:
      > >
      > >
      > > On 02/26/2010 08:09 AM, Alla Zollers wrote:
      > > > Hi Everyone --
      > > >
      > > > I am a designer currently working on an agile project and we are in
      > > iteration 0, the story discovery phase. The team has been using story
      > > trawling to discover all the various stories, and it has worked to a degree,
      > > but after some of the basic CRUD stories have been written, the more complex
      > > flows honestly require more thought and perhaps a wireframe to truly flesh
      > > out all the functionality. [...]
      > >
      > > >
      > > > I guess this bring to the forefront my biggest discomfort with agile,
      > > there is thought that needs to go into design and functionality, but when do
      > > you do this? and how do you involve the whole team?
      > > >
      > >
      > > Hi, Alla. A lot of people will have answers on this. Here's mine.
      > >
      > > My main thought is that if you are doing it right, the team should never
      > > stop thinking about design and functionality, about whole products and
      > > real users. Unfortunately, a lot of people making a waterfall transition
      > > bring along dangerous habits, like concentrating design thinking in an
      > > up-front phase, or trying to discover all the stories before starting.
      > >
      > > My experience is that the minimum you need to start the first iteration
      > > is to have enough stories defined that the team has at least an
      > > iteration's worth of work to do. That's it. Generally, that won't be a
      > > lot, as things are slow-going at the start. As that work proceeds, the
      > > product and design folks start fleshing out a sensible backlog. The
      > > backlog, in turn, makes it clear what research, what design, what
      > > thinking needs to happen so that the team is ready for future iterations.
      > >
      > > One of my teams is on something like iteration 163 right now, and shows
      > > no signs of stopping. There's no way that up front they could have
      > > discovered all the stories that they have done, let alone the ones that
      > > they will do going forward. And if they had tried, a lot of the work
      > > would have been wrong: the best designs come from the best information,
      > > and the later you are in the project, the more information you have.
      > >
      > > So instead of creating a plan and trusting it, put your faith in the
      > > team's ability to learn, to discover, to create. The shift that you need
      > > to make is from being plan-driven to being planning-driven. Which might
      > > sound like a small step, but it's a scary one: you're giving up the
      > > thing that made you feel safe before, and you haven't yet experienced
      > > success with the new approach.
      > >
      > > William
      > >
      > >
      > >
    • Show all 15 messages in this topic