How to implement unit testing with a small Scrum team without spending half the Sprint unit-testing stories?

Question

We are a very small team (1 front-end developer, 1 back-end developer/solution architect, 1 PM/UX) working in Scrum with 2 weeks Sprints.

Up until now, we were mostly working on prototype projects not requiring any testing but one of our MVPs is gaining traction and we've started implementing unit testing as part of our Definition of Done for our user stories.

However, we're now having an issue where testing is taking as much time, if not more, than the development/coding time for two main reasons:

1. My devs are not used to the unit testing framework and are still learning.
2. There are only two of them, each with their own specialty (front-end and back-end) so they have to do both the coding and the unit testing for their side of the stories.

This has led us to fail sprints because unit testing ends up taking so long that the stories don't get finished before the end of the Sprint. This becomes problematic for medium-sized stories that can't be split into smaller stories because when we add unit-testing estimation, it ends up making these stories so large that a single story ends up taking up almost half of the Sprint capacity.

Would you have any tips on how to improve this process so that testing is more streamlined/faster? Our front-end is using React and currently using JEST for unit testing, and our back-end is built with .NET on AWS but hasn't started implementing unit testing just yet.

Answer 1

My devs are not used to unit testing framework and are still learning

This will improve over time as they gain more experience.

There are only 2 of them and each with their specialty (Front-end and back-end) so they have to do both the coding and the unit testing for their side of the stories.

That is absolutely normal. Who else would write tests? Even if you had someone else to write tests, you would need to hire and pay them probably at the same rate as the developers. Tests do not magically appear.

This has led us to fail sprints because unit testing ends up taking so long that the stories don't get finished before the end of the sprint.

Yes. Your estimations are completely off, because up to now you have not delivered working , production ready software, you have delivered half-tested prototypes. And that's fine for prototypes, that's what they are: not production ready. That's the whole point of a prototype, get something going, don't get bogged down in details, show that a concept can be done. But now you need to deliver production quality software. And that takes longer than prototypes. There is little you can do. Improve your estimations to take that into account so you don't fail sprints.

But if your team is not producing enough at the quality you need, there is no silver bullet. You need more people. Hire another Frontend developer and backend developer. Producing production ready software instead of prototypes is easily double the work.

---

Even though you did not ask: hiring more people gives you a chance to improve your processes. If you have one frontend developer and one backend developer each having knowledge of their domain, there is about zero option for teamwork. I mean sure, the backend and frontend have to talk to each other, but that's not the teamwork I'm talking about. There is no one to help with the backend if they get stuck. There is no one to ask if the frontend gets stuck on a problem. Right now you don't have a team, you have an assembly line. You need more people with the same specialty so they can help each other, and work as a team. You need to be able to compensate if one of them has a week of for vacation or has to call in sick. You need to get your team to production size. As a first step to a minimal, barebones team you could hire a full stack developer that can help on either part or the project. Better would be one more of each role. Scrum does not work very well with a two people team.

Answer 2

TL;DR

The real problem here is that your organization is framing the cost of testing as unwanted overhead, rather than as an expected and necessary cost of doing business for product development, maintenance, and support. Focus on fixing that.

Analysis and Recommendations for Reframing

Would you have any tips on how to improve this process so that testing is more streamlined/faster?

TDD and BDD are not "go faster" buttons. While teams often do get a little more efficient with testing over time, the goals of testing are more closely aligned to:

1. Reducing technical debt.
2. Eliminating certain classes of common or predictable bugs.
3. Creating executable documentation.
4. Making code more flexible through emergent design and comprehensive regression tests.
5. Making testing, support, and maintenance easier by designing the code for testing and debugging right up front.

While these things often make adding new features or finding/fixing bugs easier in the future, they don't usually make current development faster. In fact, refactoring (or worse, redesigning) code for testability inevitably adds short-term drag and long-term overhead. Furthermore, getting everyone up to speed on new tooling and techniques takes time and effort, and by definition will consume team capacity.

There are several things to keep in mind here:

• You will pay the costs of testing either way, either as overhead during development or as maintenance problems down the road. You might as well pay them up front since these costs are almost inevitable.
• Regardless of whether you pay the costs in TDD/BDD or leave them to become drag from technical debt, all costs (including the cost of testing) should be visibly charged against the project. In Scrum, you do this by adding TDD/BDD to the Definition of Done and bake it into your Product Backlog estimates.

Note that in many agile frameworks, it's also perfectly acceptable to add architectural runway items directly to the Product Backlog. Since you're in the process of adopting a new testing approach, the work related related to tooling, training, and other overhead that can't otherwise be attributed to a typical feature can and should be prioritized by the Product Owner on the Product Backlog. This ensures that this necessary work is treated as planned work rather than as unexpected or undesirable overhead. When using this approach, architectural runway and testing activities are properly treated as a cost of doing business.

Answer 3

To echo what the others have hinted at:

Testing is not a necessary evil.

Testing is a crucial component of delivering quality (or at least working) software.

Keep in mind that you only get one chance to make a first impression and delivering buggy software destroys your reputation.

So, to answer your question: You need to budget in more time for testing - and even more time for fixing bugs that are discovered once testing begins.

To "to improve this process so that testing is more streamlined/faster", make testing the focus, not a punishment added on post-scheduling.

So, how do you go about that?

You mention that your stories are large and cannot be shrunk. Possibly you need the help of an experienced Technical Project Manager, to help explain to your team how to shrink the stories.

Large stories = large chunks of code = more chance of bugs = harder to fix.

An experienced (ex-)programmer/PjM will show your team how to shrink your stories into manageable bites (or bytes).

E.g. Techniques such as stubbing would be used; as you progress, you turn each stub into real code. But meanwhile you have lots of small stories - one per function - that can be coded and unit-tested, and even peer-reviewed, since they are of a manageable size with a single function.

And it won't take longer - it will probably shrink the timeline as more time is put into planning the code before it's written.