Breaking Down and Architecting Epic Features

One of my recent experiences on a large project rewrite got me thinking how a project team would break down large feature sets. One day, a specification document for a very large ‘module’ built from an existing flag ship product landed on peoples desks that was over 100 pages large. When dealing with that kind of large information, without an Agile mindset, the natural reaction of the team was to read through that 100 page specification and ultimately hand it to the development team when one is comfortable with what it says should be done. You’re hoping here that the development team will swallow that same epic amount of information and simply do what’s asked – what could go wrong?


With my Agile experience, my head was spinning on the constraints this was going to put on the project at this point. Time to pop on the systems thinking hat.

Let’s assume for a second the product team are happy with that document, and off it goes to the development team. If this lands in the hands of a developer, you’re running the risk that this developer has the Agile mindset and will breakdown this information appropriately, designing the code to handle everything in this document with a sprinkle of future proofing and just enough architecture to handle what’s in there. If you’re lucky enough to have a large team with an architect who can break that down before it gets to the development team then great. Now, I know what you might be thinking at this point, it stinks of waterfall, and you’re right, we’ll address this in a moment.

Here is the first key point I’m trying to make when dealing with large amounts of information in projects that ultimately need developers to act on and deliver. Breaking down information when it lands on the developers desk isn’t the only place breakdown should occur. There is no such thing as a product rewrite from simply one technology to another. People change things and want to make things better from previous generations of software – changes will occur. By the time the developer has chewed through that same document to implement it, the business/customer may and probably will change its requirements.

Breaking down information/features should happen as early in the software process as possible.

It’s not until the changed features are in development and the end user explores the new interface/platform that they begin to have ideas about what it is exactly they want to change in the new product. As developers at least, we know this, this is what Agile has taught us or even our own experience. We know people change their minds when they start working and demoing the software. To optimise this way of working throughout the whole process, we spread the idea of breakdown right on the first day of seeing that 100 page specification document. Information being kept small means it goes through your entire software process faster, giving faster feedback, and more opportunity to readdress and redirect.

How Breakdown Affects Architecture

When the information is broke down so all elements of the software process are invoked more often, this creates an affect on the architecture of the application. For example, if you choose not to consider everything in an epic feature, how will you know how big it really is, and how much code scaffolding you need to implement to future proof the entire feature development? Hindsight can be a wonderful thing.

The key here is scouting the specifications for key architecture points. Design fundamentals such as an application being multilingual, multi-currency etc. absolutely need to be considered right at project inception. An experienced product team or developer will know to ask these kind of questions very early on in a project. One of the more common questions is, to what capacity does it need to scale to?

If the team don’t go looking for these kind of key points, and they are realised later on, they are really going to smash through the architecture of an application, causing a lot of rework if done very late in the product and are very sweeping design points. Absorbing these kind of design points early really depends on the experience of the team.

The line has to be drawn somewhere, and no matter where you draw it, it won’t be perfect. The future proofing decisions will be made from database structure, deployment strategies, to UI/UX design etc. If you talk over your constraints in the project and let them guide you to the decisions of what you come to know as the ultimate “must be in” features, and the less important points can be dropped and considered in the future, if they occur.

Examples of early key decisions:

  • Is it going to be multilingual?
  • Is it going to be multi currency?
  • Should this application run on both browsers and tablets as an application?

Examples of deferrable design decisions:

  • Should the icon look like X, or Y?
  • Should the transition effect of the menu display be like X, or is it better with Y?

Talking about the deferrable design decisions may cause developers to build in future proof code for good reason. For example, when the decision being made has a result in all options to produce work, rather than a result that possibly means the work is not done at all.

I hope this post helps when embarking on large project rewrites or trying to consume large feature requests. Let me know in the comments if you’ve had a different experience or disagree with anything.

This entry was posted in Agile, Project Management and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s