So the project is not going as planned. Delivering features takes forever, anything that passes is often returned for additional modifications. The client is understandably unhappy about the pace, and morale within the team is going downhill. What happened? Perhaps the team is sculpting rather than developing. 

What is sculpting?

As a formal term in software engineering, it doesn’t exist. I made it up. It does, however, give insight into a rather frequent problem. Consider this scenario: a feature is requested by the client, or even a client-side product owner. It’s pushed with relatively high priority, a developer puts days into it, clarifying some unknowns with the client along the way, and when it comes to the client-acceptance testing it is generally accepted, buuut some changes are suggested. The task goes back into ‘in progress’, additional changes are implemented, in the next round of acceptance tests the feature itself passes, but it’s soon discovered that it doesn’t mesh with previously set up features and additional changes are required. Worst case scenario – the feature has to be started over because so many things were not taken into consideration. The story takes a month, the client is angry, the developer is either angry or loses motivation. Sound familiar? You’ve just witnessed sculpting, the act of slowly forming a feature after multiple back and forths, often with ripple effects on other features that then require adjustment as well.

‘Isn’t that the basis of iterative development though?’, you might ask. The answer is no, not in that form. Such delivery flow leads to significant slowdowns in feature completion, makes development more difficult and ultimately degrades the team/company-client relationship. 

What causes sculpting?

The lack of sufficient planning. While that’s more of a final link in a longer chain that leads to sculpting itself, in my experience there are a number of possible causes that lead up to that point:

• vague requirements for features – the final, useful shape of the feature is not understood well by the development team. Also leads to additional wasted time on back-and-forth calls for clarification along the way
• no breakdown of stories into tasks – prevents the team from figuring out possible roadblocks and uncovering more unknowns in time.
• no estimations – prevents the team from gauging how many stories can be handled within a single sprint, increasing the chance that stories go incomplete and are continuously carried over from one sprint to the next

When these elements are present, the precision of the delivery will always be low. Even if code is up to every imaginable standard and the features match the (vague) descriptions, the client is likely not to be satisfied with what they’re given. The conditions are ripe for a constant back-and-forth of additional requested changes within the same story

How to combat it?

Features require more in-depth planning. A lot of complexity and interconnectedness can be anticipated if stories are examined closely prior to inserting them into sprints. I’ve seen (and you likely have too) teams eschew refinements and only do rudimentary planning – this is where the trouble begins. A story with only a sentence or two explaining its aims is very likely to fail. The following steps have produced the best results in my experience:

• stories can only enter a sprint if they’re estimated
• stories can only be estimated if they’re broken down into tasks – each task should more or less be completable in a day or less. This step often uncovers the actual complexity of the story. If the task list grows large you might consider breaking the story down into smaller ones, or at the very least set up tasks in such a way that they can be worked on in parallel by multiple developers
• stories can only be broken down into tasks if they have a complete set of acceptance criteria – if you find that unclear requirements prevent you from properly setting up tasks then they have to be confirmed with the client. Otherwise you’re risking having the story come back again because something was not taken into account
• a robust forward-looking backlog has to be maintained – if, during refinement, you find that the stories available cannot be processed then you’re either going to be meeting with the team again after clarifications (using up everyone’s time) or you’re going to be forced to start the next sprint with unclear requirements and imprecise estimations, bringing you back to square one. If, on the other hand, there are more prepared stories you can always come back to this one before the next sprint, having clarified it in the meantime.

The last step in particular might require changes to how the work is planned on a high level. You will likely need more input from the client ahead of time, and in many cases this is going to be difficult due to the lack of experience with software development or vision on the side of the client. In such a case it falls back to you to help them with forward planning… and making them realise that without this the development will be longer, more tedious for everyone and – most of all – costlier. If this part is a recurring problem you might consider cyclical workshops between the client and people most involved with requirements themselves (depending on your structure it could be UI/UX designers, senior/lead developers, product owners, testers). Consider also, that each of these steps is a significant issue on its own that could use its own article and will likely take time to polish and properly implement.

Conclusion

Sculpting is a common problem causing unnecessary tension, time and cost overruns. It demands further discipline and forward planning from everyone involved. The efficiency gains and increased smoothness of cooperation are, however, definitely worth the effort.