Agile Solution Design [closed]

Question

The company I work for has just started using Agile (Scrum) for a huge project I'm working on.

As the lead developer, I have been tasked to design the solution for the Epic my team is working on.

The Epic is "Login and Registration". We're currently working on Registration, which has a number of User Stories.

The way I'm being asked to do my solution design, is per User Story, so that once the solution design for a User Story has been completed, the other devs in my team can implement it.

My problem with this is, it's really hard to do a good design when you're not looking ahead at the whole journey. Plus as I'm designing each User Story, I find a whole heap of problems with the design of the previous User Story and have to wait for Product Owners to answer questions.

The designs I'm doing don't go into the nitty gritty detail, they're just used so that we know which application layer is doing what... the finer implementation details are mostly left to the developers.

My question is - what is the correct appoach to solution design in Agile? Should it be per User Story, with iterations of improved design.... or it be a solution design for the whole registration process, and do iterations of improved design for the whole journey and we go along?

Answer 1

Let's think of the two extreme approaches. You could do all your design up-front or you could do a design on a story by story basis.

Both approaches have advantages and disadvantages. In the Extreme Programming (XP) methodology they do design in a just-in-time fashion. When using XP you are better prepared for changes in requirements as your approach is designed to change direction quickly. However with XP there may be a lot of time spent on refactoring.

With up-front design you can think of the big picture and potentially come up with a design that is more effective than one done a requirement at a time. However an up-front design can sometimes lead to resistance to change: "we can't add that new requirement as it does not fit in to the design". It can also mean the team is not practised in making rapid design changes in response to requirement changes.

Scrum teams usually operate somewhere between these two extremes. They try and find a balance between responding to change and efficient design. There are a number of factors to take in to account when deciding your approach:

• How often do your requirements change?
• How much technical risk do you have?
• Are there external factors like regulation or compliance?

I would argue that the best approach is the one that produces a decent design (but not the best possible design) and also allows the team to rapidly adapt to changing requirements.