Avoiding a Super Mario Bros. Approach to Building Features

Have you ever played the video game Super Mario Bros.?

There is a good chance a majority of the DZone audience have played or watched someone play the flagship game from Nintendo, that was originally released in 1985 for the Nintendo Entertainment System.

Super Mario Bros

For those who are not familiar with the game: you are Mario (and sometimes his younger brother Luigi) and you are on a quest to save Princess Toadstool from the evil Bowser.

Mario and Luigi are originally plumbers from New York, NY (USA) who were tasked with saving the world from strange creatures in the sewer system as the plot from the 2D arcade-based game Mario Bros. released in arcades in 1983.

Now, Mario (and Luigi) have to navigate across side-scrolling levels in order to complete the level within a given amount of time. Along the way, there are abilities to pick up coins, destroy crates and enemies to yield a higher score.

However, as the levels advance, so does the difficulty, making it more difficult to gather all the possible points before the level timer reaches zero.

Feature Development

While working on a feature development team, objectives and acceptance criteria are established as part of the Agile ceremonies. In fact, prior to bringing a given story into a Sprint, the team will have already reviewed and scored the story based upon the level of difficulty surrounding the requirements and acceptance criteria. The team, as a collective, will decide what is added (and not added) to the next Sprint — sometimes using a fist-of-five voting system.

The key to a good Agile team is to complete and validate the feature based upon the acceptance criteria within the Story used to track the associated sub-tasks.

Going For the High Score

As a developer, it is hard to avoid wanting to design and architect a solution that not only meets the acceptance criteria, but also hits some bonus items along the way.

Perhaps, the story asks for an enhancement to allow a Sales Manager to search for and open an order from the system. Security exists within the application to restrict the orders returned for the Sales Manager's staff and geographical territory. The expectation is to simply return "order does not exist" on the screen when searching for orders tied to another Sales Manager. Instead, the developer decides to provide suggestions for similar orders, based upon the order number provided.

While meeting the need of the story, the developer took an approach similar to beating a level within Super Mario Bros. Taking this time may provide some bonus points to the Product Owner, but could easily backfire when the suggestions are more confusing to the Sales Manager's using the application. As a result, taking the extra time to add something that wasn't requested only took away time that could be applied to another story.

Conclusion

Playing video games are a lot of fun. I remember trying to find all of the "Easter eggs" in games like Super Mario Bros. — often repeating levels over and over again until I fully exhausted the bonus items. What I didn't realize is that taking all of this time took away the time I could have spent actually trying to rescue Princess Toadstool — which was buried in a harder level that I am not sure I ever reached.

As team members, we have to recognize there will always be hidden gems along the way with our development quests. The key is to remain focused on the task at hand, delivering what is expected, then moving on to the next piece of work expected by the team.

Have a really great day!