Avoiding crunch at the end of development sprints

Avoiding crunch at the end of development sprints

Last week, Daniel laid out his way of keeping cool during stressful situations . Below, I outline three steps I take to avoid crunch at the end of development sprints.

Here are three personal philosophies I incorporate into my workflow to avoid crunch:

Set the team, not yourself, up for success

If you find yourself in a role similar to myself (what up business analysts!) you know that, while you do a lot of the pre-work for the team, you never do any actual development work. Make sure that every feature is ready to work on when an engineer or designer picks it up. Eliminate any ambiguity between what has been created for the team and what the client is expecting.

Check out how to write user stories that don’t suck. Engineers and designers are naturally creative individuals. When you put them together on a team they will tackle complex problems. Give them a clear set of acceptance criteria and let them solve how to build user stories into a software application.

Display energy and charisma

This is a quick and easy win. Always pump yourself up before hopping into standups or general meetings with the team. Be the most excited individual in the room. Get everyone excited about what you are working on.

Make sure they understand the requirements of whatever they are working on (see step #1) and that they are excited to dive in. This excitement will carry over into their workflow and make them knock out feature requests more quickly and more efficiently. After several days of attacking issues with enthusiasm, the team will have increased productivity and will put everyone in a better place to avoid crunch.

Know when to stop

Like Daniel mentioned in Revelry’s last blog post, know when to stop. This relates directly to development cycles as well. Don’t aim to be pushing code an hour before a demo. It’s better to draw a line in the sand, thoroughly test functionality, and address any bugs than go into crunch mode.

This will allow the team to demo complete feature sets to the client rather than steamroll through buggy code. It will also set your team to focus on new functionality for the next development cycle rather than having to fix bugs. Build complete features, don’t get

Revelry is by no means perfect at executing these three items. We’ve had growing pains and realize that we will continually be optimizing our business processes. However, we are continuing to improve using these guidelines as our backbone to avoid crunch.

More Posts by Sean Rowland: