At TNP we worked using story points to estimate and control the amount of work everybody on the team was doing, but we decided to ditch it, here is why.

We discovered several problems:

• People were stressed to finish their points, and they couldn’t focus on helping each other because they wanted to end their user stories. This issue was pushing individualism rather than quality and ship feature focus.

• Having story points wasn’t pointing us to build faster or with more quality. User story points weren’t focusing the work on value but rather on risk, time, and complexity of the user story and features. 1-week sprints were making everything worse due to this fact when we finished features that weren’t good enough to put in production and were coming back to haunt us.

We always like to iterate on processes to improve it and reduce friction at maximum, so everybody is comfortable working and focusing on delivering as much value as possible. With this idea, we decided to focus much more on delivery, following some rules.

We have two-week sprints, and we organize teams by features, so everybody is on board to ship the feature and responsible for it. We don’t have departments, but feature teams with different roles. I haven’t invented this. It’s from The Nature of Software Development book that @stanete recommended some time ago. Every user story or feature has a team behind, design, product, development, and everybody is needed to accomplish it.

We had to improve user story definition, make them more shippable and self-contained so we could deploy each of them with value for the client. That’s why we decided to be much more product-oriented. Make those minimum viable features to adjust the value and time consumption working on them. This idea is probably the most difficult to achieve. Still, we think it is better to work in this direction rather than trying to estimate better, which won’t focus on deliverability but internal needs.

This new way of working makes it more natural to have other advantages for the team. For example, when someone finished their stories early, he/she has to help the rest of the team on the features to complete for this sprint so we can ship as a team. We have time every week to learn in the process because we’re not stressed, and the time is much less tight. Improve accomplishment managing scope rather than improving estimates. We plan to do as much as in the last iteration to do good work at a consistent pace.

In the case of engineering tasks and reducing technical debt, we follow the rule ‘leave the campground better than you found it.’ I have adopted that rule for years since I read Clean Code, but all the team must stay in tune, so every time we do a feature, we can clean up the area where we are going to work. We’re exhaustive on testing and good quality code to avoid technical debt. We also try to move the QA phase of the feature as soon as possible and not only when it’s done. Once we ship, the feature shouldn’t come back with defects in it; otherwise, It disrupts our development pace.

We haven’t invented this way of working. Some of the tips are from the Influence of the Nature of Software Development and Clean Code , among other books. We’re always iterating to improve our processes and learning new things so that these changes will vary in the future.

Cover Photo by Franck V. on Unsplash