Re: Tips on writing stories for a re-architecture
- --- In email@example.com, "James Cooper"
> The purpose of the re-arch is to improve internal quality with theThis is an example of a case where I'm left wondering the best
> 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
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.
Process Improvement Manager
SysOpen Digia Plc / Telecommunications
Hämeentie 135 A, FIN-00560 Helsinki, Finland
petri.heiramo@... / +358-40-7092 526