RE: [scrumdevelopment] Re: Design process in agile
How is the story adjusted? Just as in adding the discovered Acceptance Criteria? I still vote for aiming your acceptance criteria at what you would expect the working software to do, and implement it throughout the sprint. As you discover new things, you know more about what you really wanted and can adjust on the fly.
Now this will probably result in you discovering that your stories were too big, and you might have a couple of sprints where you feel like you didn’t “get the stories done”. That’s a good and natural thing. It will start the process of finding the best way to make your stories smaller. The way you’ve described your team so far, I think you are definitely up to the challenge.
Thanks for the reply.
We tend to write our acceptance criteria before/during Sprint planning but it sometimes evolves throughout the sprint and the story on the board is adjusted.
Do you have a specific design story or add a design ticket on a wider story for example?
--- In firstname.lastname@example.org, "Fagan John" <john.fagan@...> wrote:
> Hi Emma -
> We have the same setup as you, 1 designer split across 2 sprint teams.
> We treat our design (creative) process like any other story within a
> sprint, with its own specific acceptance criteria. The scum team
> commits to what they think they can complete based on availability of
> the designer. The "sign-off" is the acceptance criteria, which can
> happen within a sprint. A story is not done done until these are met.
> The AC can contain anything that needs to be met before its done,
> including sign off from particular people and/or delivery of relevant
> documents (html or image, style guides etc..).
> If its quite a big design task, then try break it down, or complete it
> in the sprint before implementation.
> cheers, john
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Emma G
> Sent: 30 December 2011 17:26
> To: email@example.com
> Subject: [scrumdevelopment] Design process in agile
> I am interested in finding out how to handle the design process within
> an agile project.
> I'm a developer on a scrum team. We have one in-house designer who isn't
> solely in the sprints as he works for other teams as well. He creates
> the initial mock-ups of new pages, and either he or other developers
> will integrate this design into our solution during the sprint (usually
> as part of a wider story). We don't have an agreed design process yet.
> - Do you tend to have HTML mock-ups as part of a story (where needed?),
> or as part of grooming beforehand?
> - How do you handle design tickets on a story?
> - Are there any useful guidelines as to how the design process fits
> within agile?
> - What is your sign-off process for design and at what stage does this
> happen (e.g. desk demo of HTML, or when the design has been integrated
> into the developed page)
> Any suggestions or personal experience of how design fits into agile
> would be appreciated.
About the headphones….its really hard to pair program when someone is wearing headphones! J I really like to work on encouraging folks to work together. Headphones are really just portable walls. That isn’t to say I would *ban* headphones, as that is a fairly command and control kind of thing, but I would put a ton of time and energy into encouraging a more interactive environment. That complex method becomes much easier to implement when you are working the idea with someone else.
Good to hear you've tried this approach too and thanks for the advice on how to get it to work.
Do your team not use headphones at all then? I can see both sides of this, the only thing is when working on something particularly complex, e.g. coding a complex method or analysing a difficult business process, where you really need to concentrate, I think headphones can be useful.
We tend to have a mixture of design stories and design tickets on stories. So do you do the design iteratively rather than before you start the story? We are thinking of using Balsamiq where needed instead of mock-ups.
We have started trying to iron out our definition of DONE. There is a list of all tasks that may form a done story (e.g. BDD, CMS'd up etc), and then each story is tasked up appropriately as not all stories require each task of done. This is something new we have introduced after feedback during the retrospectives.
Looking at the product frequently: so the product owner and rest of team reviewing the product throughout the sprint presumably?
Working software by the end of the sprint is the goal indeed, and it's good to have this in the front of our minds.
--- In firstname.lastname@example.org, Andrew Burrows <andy@...> wrote:
> Hey Emma,
> I'm the scrum master on a team developing social games for Facebook. We
> work in exactly the way Steve Ropa described in his email earlier today. We
> haven't always, and it was a big step for the team to move away from a lot
> of pre-design - design documents, wireframes, comps, etc.... The best thing
> you can do to aid the transition is to establish an environment where the
> team is eager to improve, ready for intense collaboration (it's not a great
> environment for devs with headphones and they should be ready for the
> change) and not afraid of failing a few times while you iron out the
> From your end, clarity on story requirements is vital. If you feel that
> your definitions of done for stories are vague, work on tightening them up.
> A team should know where they need to get to, and then figure out how to
> get there during the sprint. You should also look at your product
> frequently during a sprint to asses the work you're producing, ensure
> you're still moving in the right direction, or if it's just not working out
> and you can reward the team for failing fast.
> (It may sound weird, but failure is a big advantage of working this way. By
> your earlier emails, you currently have a sprint of design followed by a
> sprint of implementation. If you run 5 day sprints, the earliest you'll
> find that you don't like the product is probably 6 days (assuming 5 days of
> design, then reviewing the first day of implementation work). By focusing
> on working software, you can find out you don't like the product much
> faster, and then fix it sooner. :) )
> Good luck,
> On Wed, Jan 4, 2012 at 12:38 PM, Emma G <emmagarland77@...> wrote:
> > **
> > Hi Dave,
> > The point you make about the team members being willing to do anything for
> > the sprint, similarly to Steve's point about developers trying out
> > designing a page, has struck home. It is sometimes too easy to stick to
> > predefined roles, and not think outside the realms of what you normally do.
> > Everyone getting involved in testing for example, in order to get the
> > sprint finished, is something we realise we need to be more proactive at
> > doing in order to get a story done, rather than taking on a new story.
> > Great feedback everyone, I have fed back to the team already and I think I
> > will bring these points up in the retro.
> > Thanks
> > Emma
> > --- In email@example.com, David A Barrett <dave.barrett@>
> > wrote:
> > >
> > > To me this doesn't sound like anything particular to "design", but
> > simply
> > > that you've got an external resource to manage.
> > >
> > > I've found that the defining element that makes a person a team member
> > is
> > > whether or not they would do *anything* to move the project along. This
> > > could be stuffing envelopes, cleaning whiteboards, solving quadratic
> > > equations, double checking calculations, testing GUI's, maybe even
> > coding
> > > --- anything, even if it isn't within their speciality. If somebody
> > isn't
> > > available to do *anything* when the project needs it, then they're not a
> > > team member. End of discussion.
> > >
> > > People that aren't team members are, for lack of a better term, an
> > > external resource. From a Scrum context, it's best to treat them as
> > such.
> > > As chickens, if you like. So they don't come to daily standups, and they
> > > aren't part of retrospectives and so on. What that means is that the
> > team
> > > takes responsibility for the work that the external resource is supposed
> > > to deliver, and they figure out a way to manage that resource. That
> > > could mean coordinating with other teams that share the resource,
> > defining
> > > how the work is passed to the resource, monitoring progress and all of
> > the
> > > other stuff that comes up.
> > >
> > > But if you try to treat them like they are a team member, you'll have
> > all
> > > kinds of insoluble problems and probably end up saying something like,
> > > "Scrum doesn't handle this well".
> > >
> > >
> > >
> > > Dave Barrett
> > >
> > >
> > > This e-mail may be privileged and/or confidential, and the sender does
> > not
> > > waive any related rights and obligations. Any distribution, use or
> > copying
> > > of this e-mail or the information it contains by other than an intended
> > > recipient is unauthorized. If you received this e-mail in error, please
> > > delete it and advise me (by return e-mail or otherwise) immediately.
> > >
> > > Ce courrier électronique est confidentiel et protégé. L'expéditeur ne
> > > renonce pas aux droits et obligations qui s'y rapportent. Toute
> > diffusion,
> > > utilisation ou copie de ce message ou des renseignements qu'il contient
> > > par une personne autre que le (les) destinataire(s) désigné(s) est
> > > interdite. Si vous recevez ce courrier électronique par erreur, veuillez
> > > le supprimer et m'en aviser immédiatement, par retour de courrier
> > > électronique ou par un autre moyen.
> > >
> Andrew Burrows
> Managing Producer, Large Animal Games
> Call me: 212-989-4312
> Follow me: @readytoscrumble
> We're Hiring: http://largeanimal.com/jobs