Scrumfall to Agile Transition Hurdles

Image for post
Image for post
Photo credit: rawpixel @ pixabay
  • Task-based assignments with hour estimations were always padded
  • A four-week sprint was too inflexible and difficult to plan accurately

Serial Stages

In the waterfall process, there would be a requirement gathering stage where a manager would talk to the product manager to work out the requirements. Then the team would review the requirements and maybe adjust them a bit. Eventually, the design starts as one senior developer would write up a design doc. Then the rest of the developers would read, comment, and ultimately sign off on the design before any development could start. If the feature was very complicated, the design might take days to write up before reviewed. Then a test plan is written according to requirements and the design. The rest of the team would read, comment, and ultimately sign off before the QA engineers created tests.

Story Points

Story points are abstract units based on complexity. They have a steep learning curve as many people find it difficult to let go of the hour estimates because time is a tangible concept. A person can look at the clock and see the seconds, minutes, and hours passing. A pattern I noticed was some people used story points as time. The first common issue I saw is using story points as hours of work, and the other problem is translating story points to hours. Both of these methods are common pitfalls because they are incorrect ways to use story points. To get my team passed the hour issue, I chose the Fibonacci number sequence and started with planning poker to abstractly establish what the user stories were worth. The first sprint was rough because the estimates were all over the place, but they began converging over time as people grasp what the worth of the story point values are.

User Story

Another steep learning curve is going to user stories from task assignments. It’s another concept that people have trouble adjusting. A task is something like “create a database to hold passwords for the application” while a user story is more of a description of a feature from a user’s perspective. Does this user directly interact with the database? No? That’s not a user story.

Shorter Sprints

Transitioning to two-week sprints was met with initial resistance as some team members felt there would be too much planning overhead, but the change turned out to be one of the easier ones to see the immediate benefits. With a shorter sprint, the time spent planning became shorter because there were fewer items that needed to be discussed and estimated. There was time to react to changes in priorities or even when new information is found. The shorter sprint gave much-needed flexibility in adjusting to problems as they come up.


Initially, productivity dipped in the first few months as the team was adjusting to a new paradigm and process. Some of the hurdles needed Agile training to help move the team over from the waterfall method, but the benefits became apparent as the team became more reliable, flexible, and faster. Features were estimated more accurately with story points. Planning was reduced with user stories and changes to the design process. The shorter sprint allowed more flexible adjustments to priorities or information discovered. Overall, the team was given more autonomy and performed much better than it did before the changes.

Engineering leader. Software Developer. Problem solver. Failing forward.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store