There are many ways to analyse and write down business needs and hand them over to developers for implementation.

In many cases knowledge and information gets lost in translation and/or developers don’t understand exactly what to build and come up with their own solutions and the scope gets bigger and bigger, also called scope creep.

So, how can we get to a shared understanding of the business needs and prevent scope creep?

This is where the combination of EventModeling and ShapeUp comes in play.

ShapeUp

ShapeUp is a way of working for product development at BaseCamp.

This method aims to be more effective than other product development methods by using clear structures and processes. ShapeUp is about shaping a solution, so it can be implemented within one cycle.

For now I take just a few key elements, but I can recommend to read the 15 small chapters to fully grasp it.

Cycle time

Traditionally, with methods like Scrum, many prefer a cycle of two weeks, but BaseCamp decided six weeks is ideal. For BaseCamp six weeks is short enough to oversee and it is long enough to get things done. But you have to decide yourself which cycle time works best for you.

Shaping

Shaping has three simple principles: it’s rough, it’s solved and it’s bounded. This means the proposed solution doesn’t have much implementation details, any pitfalls or rabbit holes are identified and there’s a clear start and ending of the work package. The work needs to be shaped so it fits within 1 cycle. If it doesn’t fit, it either needs to be made smaller or needs to be break down.

EventModeling

With EventModeling a business process is described in such a way, that it has enough information to implement a system. The most important elements used with EventModeling are: Events, Commands, Read Models, Automations, and Screens.

  • An Event describes a fact or decision in the business process, like 'Shipment Started'

  • A Command describes an action which can be performed on the system, such as’Start shipment'

  • A Read Model describes the output of the system, for example 'Shipments'

  • An Automation describes an automated process, like 'Generate Send Label'

  • A Screen describes the UX/UI

A simple EventModeling blueprint:

EventModeling Blueprint sample

As you can see, all information is there and everybody, from business to development, can understand the flow of information.

Shape Up + EventModeling == rough + solved + bounded

When combining Shape Up with EventModeling you get a system or product design which complies with the three properties of shaping: rough, solved and bounded.

It is rough, because the EventModeling blueprint doesn’t show how it needs to be implemented; it is technology-agnostic.

It is solved, because the EventModeling blueprint shows us exactly how the information flows through the system, from screen to system back to screen.

It is bounded, because you can slice an EventModeling blueprint easily to work packages for teams to implement

EventModeling Blueprint slicing sample

As you can see, the slice of the screen can be developed separately from the slice which includes the command and the event implementation. Or if the whole flow fits within your chosen cycle time, do it within even one cycle!

A special thanks goes to

I’d like to thank a few people who inspired me:

shadow-left