We recently wrapped up the initial MVP of Enzyme, our Polkadot wallet, and I wanted to share some insights about the development process from the perspective of a Project Manager. My first anniversary at BlockX Labs is coming up in a couple of weeks and it's been amazing to see the progress the team has made. I've managed three major projects during the past year and Enzyme has been the smoothest. This is partially due to us just being more efficient and better at our jobs, but there was one thing we did during sprint Planning that really made a big difference: breaking stories down.

For those who aren't yet familiar, Agile is a software development methodology that is about building working software quickly and iterating from there, rather than architecting the entire software first and building it at the end. Scrum is a framework within the Agile methodology based on sprints (time-boxed units, usually two weeks) that contain User Stories (user-centric end-to-end descriptions of a feature). The number of user stories in a sprint is based on the sum of the difficulty value (points) of all the stories in the sprint relative to the number of points completed in the previous sprints (or estimated for sprint 1). So if the development team had completed 20 points worth of user stories the previous sprint, they'd accept around the same number of points for this upcoming sprint.

Before the start of the project and before each sprint, User Stories are written by the Product Owner and based on customer and/or user requirements. During sprint planning before a sprint starts, it's up to the development team to ask questions, get additional details, and clarify what the user story is about so that they can implement it without ambiguity. If a User Story is ambiguous, estimating it's difficulty is much more difficult and makes sprint planning less accurate. If each story ends up being 1/2 as difficult or twice as difficult as expected, the development team can be anywhere running out of work half way through the sprint to only completing half the accepted user stories. If this inaccuracy occurs regularly, projects can end up taking significantly longer than expected.

So we've established that it's incredibly important to get small estimates as accurate as possible in order to keep major milestones accurate. The way that we became adept at story point estimation during Enzyme was done two ways:

1. Split user stories into multiple stories
2. If a user story can't be broken down further, create sub-tasks for the individual components of the user story

Split user stories into multiple stories

Much like the Ma Bell monopoly needing to be split up in the US in the 1980's, user stories can be split up as well. Reducing the scope of user stories makes them more focused, easier to estimate, and faster to implement.

One can split them based on a few different patterns, such as the steps in a workflow, variations on input data, going from simple to complex, and more.

Example: Workflow Steps

• As a content manager, I can publish a news story to the corporate website.

This can be split into:

• …I can publish a news story directly to the corporate website.
• …I can publish a news story with editor review.
• …I can publish a news story from the staging site to production.

I got this example from Richard Lawrence's agileforall.com. Have a look at the rest at agileforall.com.

Create sub-tasks for individual components

If a story can't be further split, break it down into sub-tasks for the individual components of the story.

The benefit of this is twofold:

1. Developers can help plan out the work involved and self-assign parts of the story.
2. As a result of understanding what's involved, their estimates are more accurate. This was the main benefit for us at BlockX.

Example: As a user, I can authenticate with a username and password

Sub-tasks:

• Front-end: what should it look like?
• Backend: how should it present itself to the frontend, and how should it interact with the database layer?
• Database: do tables need to be created? What are the required columns and data types?

For all of these sub-tasks, what dependencies need to be available before even starting them? (In Jira, they can be linked to other issues using the "blocked by" type.)

It's okay for developers to plan out how each sub-task will be executed, even if it ends up needing to be changed. The whole point of this is to get them thinking about implementation.

</end>

Once the sub-tasks are discussed and thought about, doing relative estimation will be much more accurate because developers will have thought of both implementation and some edge cases during the discussion. The basic currency unit of Scrum (story points) is solidified, making every step in the hierarchy more accurate.

It may seem like an unnecessary step, but in my experience it's worked well!