Listen to the article
You wouldn’t build a house without blueprints…right? Then why would you try to scope work for new features without thorough documentation?
Proper documentation of prospective feature work is a vital and often overlooked, step in creating workable features. Too often we’ll see project teams want to jump right into development of a feature without taking a thorough look into why they’re doing it, and what they expect to get out of the project. Taking the extra time to plan out your features will help you reduce the time it takes to get a feature to market, improve the end results, and reduce development costs in the long run. You’ll look back on your properly documented feature and be glad that you took the time to thoroughly plan out your work!
So, what should you be documenting?
I always encourage clients to take a thorough look into why they’re doing something, and just as importantly, what they expect from the end result. Even the most minor of changes should have a measurable goal behind them. We always suggest considering a few of the following points, long before a feature makes it into development:
- What problem are you trying to fix?
- What benefits will this feature give the end-User?
- If you’re trying to save money, how much? And, what is the benefit to your organization?
Understanding your risks allows you to get out in front of an issue before it becomes a disaster. This is where your entire team comes together to identify issues that could result from a feature. Even the most simple of changes can have a significant effect on other parts of your business. Need some starting points, consider a few of these prompts:
- How could this feature go wrong?
- How will this feature affect sales and profitability?
- How will this feature affect the User flow of existing features and prospective features?
Without well-defined requirements, we often find that portions of an implementation can become muddied. Your entire team should be able to clearly define the requirements of a feature long before a developer opens a code editor. These should be clear statements that illustrate an end-result and its importance to the feature as a whole.
- Write out a quick summary point for each prospective Story that defines what you want the result to be for the User (whether that User is internal or external)
- Define its value in the scope of the project. Do you need this item for launch, is it something to iterate into a future version?
Even the smallest of front-end changes can benefit from having a design, long before any development work is started. This allows your team, and your development partner, to truly understand the changes you’re about to make to your site. Not to mention that one person’s small change may be an experience-killer in someone else’s eyes. Consider the following:
- How does a User interact with this feature?
- Is there a User flow drawn up for the feature? While designs are great to have down the road, having a clearly draw User Path can help identify any issues
- Does the design complicate the User Experience of any existing features?
Like any change we recommend implementing in your documentation and feature planning process, iteration is important! If you start implementing even one of these concepts you’ll start to see better planned, fully thought out, and ready to work features.