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

Re: Agile Framework for Requirements and Design

Expand Messages
  • stevewhisenhant
    Peter & Robert, Thanks for the feedback and comments. I agree whole heartedly about doing only what is needed. To people outside of the scrum process, I call
    Message 1 of 5 , Jul 5, 2010
    View Source
    • 0 Attachment
      Peter & Robert,

      Thanks for the feedback and comments. I agree whole heartedly about
      doing only what is needed. To people outside of the scrum process, I
      call this "just in time design". To the BAs the work for me, I preach
      "Do the right work, at the right time, with the right people."

      Peter's notion of two simultaneous processes where the output of one
      process creates inputs for the second process is close to what I have in
      mind. However, Robert hit the nail on the head with "stories to define
      stories" does not add value. The key to the meta-scrum is to find
      stories that add value for the customer (members of implementation team
      or other stakeholders) but do it in a light-weight manner that benefits,
      but does not impeede the BAs involved.

      The design meta-scrum idea was about adding framework for backlog
      maintenance within a suite of tightly integrated products. I can see
      how a workshop is valuable for a new product or new major feature of an
      existing product, but it does not seem feasible for ongoing work on that
      spans over a dozen teams.

      --- In Agile_BA_Requirements@..., Robert Merrill
      <Robert.Merrill@...> wrote:
      >
      > Steve,
      >
      > Building a good first-draft backlog can be challenging, especially for
      > people new to Agile.
      >
      > What I like to do is run a facilitated workshop with all of the major
      > stakeholders. The workshop writes user stories, identifies the
      > entities (logical data i.e. nouns) and then uses those to identify
      > additional user stories based on where the data come from and go. One
      > hard day and they've created and reviewed a first-draft backlog. Is
      > that what you were thinking about for your "Design meta-Scrum?"
      >
      > Think of all the requirements models and documents you mentioned, and
      > ask, "What's the least we can do to get started?" A user story is just
      > a really informal, low-level-of-detail use case (Cockburn's book on
      > Use Cases really helped me there). Do you really need full UI specs
      > for everything to get started, or just sketches of a few key screens?
      > Do you need a full logical data model at the start, or are entity
      > names and key relationships enough?
      >
      > One thing I'd watch out for is continuity of people. Make sure there's
      > as much overlap between your "Design meta-Scrum" and the
      > implementations as you can get. The Product Owner (person or team) has
      > to be fully involved. At least one of the developers should be there
      > too, to absorb all that tacit knowledge. Calling it a "Design Scrum"
      > rather than a "Design Sprint" (or iteration) is a stroke of brilliance
      > IMO. If people are used to working a in a task-phased (waterfall)
      > rather than a feature-phased (agile), there will be a natural pull
      > towards "Scrummerfall"--a Requirements sprint, a Design sprint, a
      > Coding sprint (or two or three)--you see the pattern. For the same
      > reason, I'd recommend
      > you not have "A story to define the stories" because that's a task,
      > not a value-adding result. The mindset shift from tasks to ultimate
      > outcomes is a really tough one for a lot of people to make, so don't
      > enable them not to.
      >
      > On the last project I set up, I didn't follow my own guidance. We had
      > a workshop to develop an information architecture, but some of the key
      > people for the user story workshop weren't available and we had an
      > integrator ready to start, so I built the backlog myself, based on the
      > IA and common BA sense. Oops.
      >
      > It took us three iterations (and some "storming") to get
      > heart-ownership of that backlog transferred from me to the Product
      > Owner team where it needed to be. We didn't have that problem with the
      > IA, because I facilitated it but the content experts built it, so it
      > was "theirs" from the start. You'll always be learning!
      >
      > --
      > Robert T. Merrill
      > Principal, uFunctional LLC
      > http://www.ufunctional.com
      > 608-692-2638 Twitter @rtmerrill
      >
      > Trustworthy, competent help with
      > Your software-intensive business
      >
      > Quoting stevewhisenhant steve.whisenhant@...:
      >
      > >
      > > I ask forgiveness from the moderators if this subject falls outside
      the
      > > forum's purpose.
      > >
      > > As I have learned and attempted to practice agile methods, such as
      > > scrum, the models and the training usually give less than sufficient
      > > attention to the process, practice, and framework for discovering
      > > requirements and translating them into the infomation teams need to
      > > implement during a sprint. Now, I know the theory... Product owners
      > > should continuously cultivate the backlog after ongoing conversation
      > > with the team about upcoming user stories. That might as well be
      magic
      > > and unicorns for those used to creating/reviewing/approving
      traditional
      > > artifacts such as use case documents and user interface
      specifications.
      > >
      > > So, I've been asking myself... What are fundamental components of
      > > working agile? How does this apply to the Business Analysis that is
      > > needed to make user stories ready to teams to consume in short
      > > time-boxed period (aka sprint)?
      > >
      > > Our Design management team is considering a Design meta-scrum as a
      > > framework to help with this problem. The concept is to create a
      backlog
      > > of stories about the work BAs and POs need to do to get the product
      > > backlog ready for the implementation team. In this context, the
      design
      > > story roughly describes a deliverable that adds value to the "real"
      > > product backlogs and the "user" is a role in the agile team or other
      > > stakeholder. We think this approach can instill a
      > > "plan-do-inspect-adapt" for requirements elicitation and grooming.
      > >
      > > How does this approach strike all of you? I am open to questions if
      my
      > > description is not clear. Thank you.
      > >
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.