It’s done! Or is it?

commercetools has been growing a lot lately, and we want to continue doing that. Not only do we have new product owners, UX experts and developers joining, we are also growing areas around the core platform teams. More sales, more training, more support, more marketing; in offices all around the world to support the growing product we’re making.

Being strong believers in independent teams, we thought about how we can ensure delivering a great product while:

  • Minimizing disruption and interference with how the platform teams work
  • Simplifying collaboration for all the other departments that contribute to the whole product

Our starting point to this is having a common Definition of Done (DoD) for features, which describes what has to be in place to call a feature “done”. And for the customer, a feature isn’t just about code that’s deployed, but the entire package. That can be all of the software’s inherent qualities, but also additional assets living next to it, like training material or documentation. Lastly, a feature is not done, if it will be a mess to maintain in the future.

Don’t confuse done in this context with complete. Most features start minimal and then keep evolving based on feedback and learnings. Done means: Whatever was defined is finished. And it’s good.

The common definition of done for features brings us three benefits:

  • Alignment on everything that’s customer facing. Consistency in APIs, documentation, wording, UX, and knowing what to expect makes their work so much easier, and leaves them with a warm and fuzzy feeling of trust.
  • Helping colleagues to get their job done. Documentation, support and training, customer success and professional services, marketing — they all contribute to the product. In the end, how much is your feature worth if nobody talks about it, understands it, or recommends it in implementation projects? A Definition of Done is like a playbook for helping everyone understand what’s expected from them (and what they can expect).
  • Setting us up for sustainable development and growth. Coming up with a Definition of Done is a fairly straightforward task, but still surprisingly time consuming. Having a common DoD for all teams lets you focus on more fun things, and at the same time ensures we all do have a shared understanding of what is required for a feature to be “done”.

How does this relate to a team’s own DoD?

If a team has their own DoD (for stories, sprints, or whatever you want), it goes deeper into details on how to achieve certain things like beautiful code, or having no (known) bugs. A company wide Definition of Done is not there to replace any of the team’s DoDs, but supplements it with a focus purely on qualities and assets visible to the outside world (that is, not the team).

Qualities

“Non-functional requirements are requirements, which, if not fulfilled, make your product non-functional.”

The software we build & deploy has to be of good quality, to be useful. Those qualities are also called non-functional requirements. Making sure those are fulfilled is the responsibility of the platform teams. It’s the responsibility of the product owners to check the quality as part of accepting the story, but they can delegate to specific quality-checkers. Delegating makes a lot of sense for topics which require expert knowledge, such as security or legal requirements.

Checklist

  • The feature solves the defined problem
  • Happy, sad and bad cases work as they should
  • UX, design, and wording are consistent and good
  • APIs are consistent and good
  • Error messages are helpful and understandable
  • Performance is okay
  • No security and privacy issues
  • No negative impact on platform stability

When is the best time?

A common concept for security and privacy is to have those built-in, by design, instead of as an afterthought. You can do the same for many other qualities: When defining the feature, you can think about performance implications, limits, API / user interface consistency and usability, architecture and modularisation, and all those things. Which is not to say you should come up with a fixed master plan before you start building, but it often does make sense to give those topics some thought. A similar approach is the Scrum-ish Definition of Ready.

Assets

Customers are not looking for the most beautiful commerce APIs, they are looking for a product to solve a problem they have. This includes support and documentation, training and consulting on implementation practices, and (obvious, but often forgotten) knowing the feature exists and is exactly what they need to help them out.

Taking care that all those things around a new feature are in place can be a bit tricky, because the people creating assets around a product feature aren’t always the ones who developed it. Being involved first-hand in feature development, product teams can help everyone a great deal — that includes giving input, answering questions, or even conducting internal training sessions. All that takes time, and it makes sense to see it as part of what you need to do, to get a feature “done”.

Checklist

  • Release notes published on all channels
  • Documentation published or updated
  • Tutorials are published
  • Training material is updated
  • Professional services knows about the feature, and best practices for using it in projects
  • Support knows enough to support the new feature
  • Sales and marketing are aware and can explain the new functionality
  • Product marketing is aware and ready to evangelise the feature
  • Customer success is aware, can explain the new functionality and update specific customers that asked for it
  • Is it a good topic to blog or talk about? Do it!

Maintainability

The last point that is covered in the feature DoD are not for customers, not for colleagues in other departments; they are for the teams. Taking care of those while still working on a feature makes work in the future easier and faster, and is an investment well worth the efforts.

Checklist

  • Automated tests to notice when bugs sneak in later (regression tests)
  • Code is easy to understand and clean
  • Architecture is clean, especially modularity and dependencies
  • Logging / monitoring is in place
  • Documentation for on-call to know what to do when things break
  • Analytics for usage, performance, stability

Conclusion

Sometimes it is better to be fast than perfect, and the benefits of going live with a new feature early outweigh the downside of not covering that one edge case, inconsistent UX, or documentation that’s still being updated. And that’s okay. The feature can still go live — just be transparent to your team and company that you’re not ‘done’ with work on it.


It’s done! Or is it? was originally published in commercetools tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Source: Commercetools

Leave a Reply

Your email address will not be published.


*