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

Re: Tips on writing stories for a re-architecture

Expand Messages
  • petriheiramo
    ... This is an example of a case where I m left wondering the best approach to using Scrum and development processes in general. You have a case where you have
    Message 1 of 12 , Jan 30, 2007
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, "James Cooper"
      <jamespcooper@...> wrote:

      > The purpose of the re-arch is to improve internal quality with the
      > hope that this will lead to increased developer velocity in the
      > future. The company has a new CTO, and he is the primary stakeholder
      > on this project. End-user functionality will be largely unchanged
      > when this re-arch is complete (we are re-using the HTML templates from
      > the current UI almost verbatim).
      > I'm helping the CTO write stories for the product backlog. He's
      > supportive of Scrum, but very fixated on the architecture. For him,
      > the architecture is a big part of the acceptance criteria.
      > This is the context I'm working within, so I'm trying to help frame
      > this work in the most agile way possible. We discussed doing
      > user-based stories, but arguably the current system already fulfills
      > those stories, hence my idea to use "as an external application" as
      > the role to highlight that the business value is the SOA
      > implementation.
      > Thoughts?

      This is an example of a case where I'm left wondering the best
      approach to using Scrum and development processes in general. You have
      a case where you have a relative stable set of requirements (a
      situation which is very likely to change when the application near
      "completion") and where you can actually predict with relatively high
      probability what to build in the future. Therefore we can argue that
      it is possible for you to bet on future and expect a reasonable
      probability of getting it correct.

      Therefore the situation would allow us to consider making some
      pre-planning on the architecture based on what we know of the existing
      solution, potentially saving some refactoring time in the development.
      However, do we know the direction into which the application will take
      once the "re-writing" is done?

      So, my gut feeling would be to suggest (if were our project) to
      consider some initial planning, for example in the form of a longer
      first sprint with a goal to redesign the architecture and prove it
      with a simple user story or two. This architecture should be the
      simplest solution to include all known functionality. After that I'd
      suggest adding user stories onto the redesigned architecture, keeping
      in mind the Agile technical practices so that the team can keep their
      velocity up when the PO actually wants to add new user stories into
      the project. I'd be inclined to believe it will happen before all the
      old functionality has been implemented... :)

      In short, use Scrum with stories describing current functionality, but
      allow the team to plan forward. This should keep the project flexible,
      but also cater to the PO's need for architectural focus.

      We've had projects similar in situation like this in the past, and I'm
      sure will have them in the future. I know that they are "simple"
      projects in comparison to those with (wildly) changing requirements.

      Petri Heiramo

      Process Improvement Manager
      SysOpen Digia Plc / Telecommunications
      Hämeentie 135 A, FIN-00560 Helsinki, Finland
      petri.heiramo@... / +358-40-7092 526
    Your message has been successfully submitted and would be delivered to recipients shortly.