Masonry — An Approach You Should Try Out

How to Build and Manage Projects From the Ground Up

When managing a project, you will rely on tools like Trello, Jira, or your own backlog in Excel. You may build a mindmap that shows how many branches your product has.

But, as a product manager who is also doing some full-stack development and working on a complex project, it’s sometimes difficult to have a good overview of what you are doing. Sure, we create our epics, our user stories, add tasks, we have sketches, and more.

But these are not methods that visualize how we build an app from zero to hero. And sometimes, it’s necessary to see what relies on what. There are ways to show us this, of course, but it can be done better just to help us.

I have been working with Masonries. A masonry is a visual bottom-up approach for project structures that I have developed to better display what tasks I have to complete before a parent task is completed and how it affects the user story or its epic. It has some similarities to Treemaps.

Fictional Example

In a fictional example, I want to show how I build and use a Masonry. In my example, we want to build an app that allows authors to write interesting blog articles.

To make it not too complex, let’s focus on just two user stories.

The image above shows us two user stories. The first is the author who wants to write and publish an article. The second one is the author who wants to view and edit or delete a published article.

What do these stories need? Apart from the second which needs a way to display all articles, we want to

• Open the article editor.
• Enable markdown syntax in the editor
• Enable image import
• Publish the article.

The colors here indicate (I apologize if you are red-green blind) that a green-marked task, enabling image import, is done. Publishing an article is in progress while enabling markdown syntex in red is yet to be done.

The parent task, opening the editor, so far, is affected as it’s yellow or “in progress.” This again affects the next task or user story.

It could, of course, be possible to have a wider brick layer below the tasks, e.g., if you need authentication for a specific feature. You can also, as seen in the example image above, reuse tasks.

Like a mason, we put brick on brick, and the user story is nothing without the completed task; the epic is nothing without the completed user stories.

In a project, you can have multiple Masonries to build a House where the house is your project.

Pros and Cons of Masonry

The pros and cons of Masonry are so far clear, I guess.

Pros:

• better visualization of dependencies
• from-scratch build-up method
• easy to read

Cons:

• Takes some time to build (no software yet)
• No time estimates or story points
• No assignments
• For paper, you need to cut out paper

The concept of Masonry is just new. But it helped me more than mind mapping to have an overview of complex projects and makes a more efficient product manager.

What’s your opinion on Masonry? Can you imagine using this approach? If you do, share your experiences. If not, please share your reasons why.

Also published here