Discuss Agilepublic

Community Agile Discussions

A variety of ongoing discussions about Agile development

This is a public Discussion Area  publicRSS

Thread

    Requirements- what is enough?
    Thread posted 6/9/09 by Jennifer M.
    12427 Views, 6 Comments
    Title:
    Requirements- what is enough?
    Content:

    I have a team that is new to Agile and is very use to having all the requirements spelled out in detail. Any ideas on how to win them over to the agile way of requirements? Also, they argue that they need to know the whole picture before they can design or code- how much of the requirements do you cover in agile in the beginning of the project? Just the first few iterations and if so how do you show the team the whole project so we don't code ourself into a corner? Thoughts?

    Comments

    • posted 6/9/09 by Hubert

      Jennifer,

      Your team asks for two separate things: seeing the whole, and design before coding. Once your product manager has figured out what she wants as a result of the project she will be able to talk to the team about 'the whole'. The time spent to create the vision and the backlog is known in Scrum as 'sprint zero'. A bit of a misnomer, as it can take a few sprints to get to the point where the vision / backlog is clear. The hard part of this stage is to not create a detailed design, but to explore the complexities, and find answers to the questions that will create success or failure for the project/product. If you explore lean concepts then you'll find the term 'set based development'. That is what the product manager and the team are doing: exploring the tough questions. Marty Cagan in his book Inspired swears by prototyping. Mary Poppendieck teaches to look at factors outside the product: how to manage factors like insufficient test people.

      And then there is the ongoing design, from iteration to iteration the team needs requirements. I ask a team which artifact works best as a communication medium: wireframes if you have a rich user experience, architecture diagrams if your product is more technology oriented (building a compiler or operating system). The product manager prepares detail in this artifact in the iteration prior to the delivery (yep, 'pure agile' asks you to do this in the iteration - not many teams manage this). During this prior iteration the product manager communicates with the team about the next deliverables, we sometimes call this 'backlog grooming'. In these sessions the team reaches the point where they understand the requirements for the next iteration, typically understanding is proven by providing storypoint estimates. And then during the delivery iteration the product manager keeps helping the team to understand the requirements, by assisting in desing sessions, and accepting requirements when the team declares them done.

      A lot of topics in a small message, let me know where you're exploring and seeking guidance.

      --Hubert

      Reply to this Comment

      Attach File

      • posted 6/9/09 by Jennifer M.

        Thanks Hubert- so when do you do the wireframes and wouldn't this mean you are deciding on the final look and feel- how much do you include in the wireframes?

        Reply to this Comment

        Attach File

    • posted 6/9/09 by Hubert

      If the user experience is key to the success of the product then use the sprint zero to learn which prototypes (could be wireframes) work best and will be developed into the full product. Once those decisions are made a typical team develops the wireframes in iteration 1, to be fleshed out in iteration 2.

      While prototyping you are indeed making decisions about look-and-feel, based on multiple prototypes and after collecting feedback on those prototypes from multiple customers and prospects.

      Makes sense, or am I missing your point here?

      --Hubert

      Reply to this Comment

      Attach File

    • posted 6/9/09 by Hubert

      You're welcome! Say "Hi" to John-Mason for me.

      --Hubert

      Reply to this Comment

      Attach File

    • posted 6/13/09 by Chris M.

      It sounds a bit like your team feels confused and lacking direction. It's worth clarifying what exactly they're worried about. If it's a general lack of direction, you might explain in 2 ways: One, give them a rough Roadmap, with no dates on it, just solid goals you'd like to accomplish, leaving out details that are yet to be determined. Something worth working towards. Two, explain that Agile is about delivering frequently to change course early when things start drifting off-course, preventing the infamous "Death March" project - experienced Developers will appreciate this. The trade-off of frequent opportunities to change course is that the team can feel like it's marching blind at times - and for that, all you can do is acknowledge the weakness, and provide what long-term plans are solid like the roadmap.

      Reply to this Comment

      Attach File