How to create Epics, Specs, User Stories in Product Management

epics user stories acceptance criteria
How does the product vision is turned into the product itself? The CEO and company executives have a vision where the company is going and what the goal is for the next 3-5 years. Company has to have goals to get to the vision. Goals are decided by the executives but defined further into metrics – for example, increase new user signups by 30% this year. Then there’re initiatives the whole company would do to achieve each of those goals. For example, revamp user sign up flow.

Underneath initiatives, there are releases. They are a group of features or functionality that is released to the public on one particular date. For instance, we have a release of new user sign up flow in May. This will be our release. The product features and functionality that are in the releases are called epics.

Epics group one or more features and functionality that we’re building to solve a problem. Usually a product team builds 3-5 epics per quarter of the year. It depends on the company and team size how many efforts the epics going to take. An example of epic would be, allow users to work with files offline and sync files when online.

The term epic usually equals feature but not all the work done on the product can be presented as the new features for the user. So epic term reduces confusion, for example migrate API version would be an epic but it’s not a feature. This epic might be done to scale or to allow more uses. Epics are defined as something that needs more than one sprint to build.

Most project management apps (Jira) allow you to create an epic and then add features (user stories) to this epic. In any case epics always have supporting documentation with them explaining what are you building and why. Sometimes it’s called epics spec sheet or requirements document. It can be hosted in Jira, Google docs or any shared resource so the company employees have access to it, can read and understand what are you building. It also works as guide for the team as you build things.

How epics specs usually look like? They usually have 4 major areas – an Introduction, Product requirements, Design requirements, Engineering requirements. Product manager is responsible for creating and maintaining epic spec sheet but especially responsible for the first two items. The introduction contains summary of what features are for and why you’re building it, what metrics you’re trying to improve? It also usually contain links to supporting documentation, marketing plans, legal requirements, what feature and functionality look like, early wireframes and what it looks like ideally vs. what are you going to build for MVP, v2, etc.

The second section is the product requirements. Here we are talking about features or functionality we’re developing in details. We go deeper on what’s required. For instance, the feature should be fast or available in certain language. Or it must generate a certain type of data and store it for later use.

The design requirements section is to be filled by PM and designer together but more from the designer side since they are the experts here. For example, you need high resolution for user picture and this will be stated in this section. It also contains early wireframes and sketches or high fidelity prototypes to help engineers better understand the requirements and what have to be done here.

Engineering requirements spec sheet section is filled out by the engineers after you discussed the product and design requirements with them. Here’s the engineers will write down the database and technology requirements or outline a series of things that must be done on the technology side in order to support new feature. For example developing new API endpoints to support high-resolution picture stated in design requirements. Or they need to know if they need to work with another team in order to access their database in order to build this new feature.

User stories and acceptance criteria are located underneath epics. With their help, you take epics and get them into developers’ hands to work on. After decision has been made of what you’re going to build, you had outlined the phases you’re going to build them in. Now you need to put this work into project management software so that the engineers can start working on it. This is where user stories and acceptance criteria come in.

User story is a way to describe a thing you’re going to build that delivers some type of functionality to the end user. For example, As a user I want to know my Spanish level accurately so I can resume my language study at the right level.

User stories always follow this format – As an x I want to do y so I can z. Why user stories have this format? Product manager usually writes them and puts into project management software. By writing them this way, you can avoid saying how something should be built on the technical level. You’re not telling engineers how to do their job you’re just telling functionally – as a user what I should be able to do.

User stories belong inside your PM tool where there’s a card with your user story and different status: to do, in progress, and done. These cards are commonly called tickets and besides user stories they contain bugs and other issues. The engineers complete the user story and move on to the next one. Before you can say that the user story is complete you need to make sure that the functionality does what you intended it to do.

This is where acceptance criteria come in; it’s a set of conditions user story must satisfy to be considered complete. Typically, acceptance criteria are written with the ticket. “Given I’m a user who has successfully completed my language assessment, I want to get a report with my accurate score and recommended level.”

AC are usually very specific because their purpose is to reflect how the feature should function. It provides a list of things you can test before releasing it to the public. This is very helpful for engineers who like everything to be very specific so that they can think through the process of engineering the stuff correctly. Product Manager is usually responsible for testing completed tickets and stories before approving them to go live.

Challenges of online money transfer startups

online money transferThe existing money transfer players – Western Union, Moneygram, banks – have no incentive to innovate because online money transfer model will significantly change their existing mostly cash based walk-in business model. It’s very unlikely that any innovation will come from them. For example, it will significantly disrupt an agent network for Western Union. Even if they have technologies, resources and ideas the existing money transfer giants hold it back. It strongly reminds of Kodak – the company, which invented digital camera but hold it back being afraid that digital technology will affect its film based business.

There are probably more than 50 startups on the red-hot market of online remittance working on worldwide scale and even more than that on the local. Most of them are unknown startups you’ve never heard of and never will. Some of the most known names are Transferwise, Azimo, WorldRemit, Zoom (PayPal division).

The major challenge for online money transfer startups lays in establishing trust and brand recognition. In the crowded market, marketing becomes very expensive and hard to do. Almost none of the online money transfer startups have ever been in black. Even the most prominent ones such as Transferwise and Azimo are reporting losses years in a row explaining it with the need to expand and grow. Even the relatively mature Xoom under PayPal umbrella continues to report losses.

Another major challenge for remittance startups is technology and infrastructure. It’s impossible to be in a money transfer business today and not rely on the infrastructure owned by banks. The large portion of the money providers also relies on well-known APIs providers such as CurrencyCloud and TransferTo. You really can’t make it cheaper or faster or give customers better rates if you rely on 3rd party provider infrastructure. The key benefits the customers want are almost impossible to improve on unless you’re doing direct partnerships and agreement and building your own infrastructure that means huge upfront costs.

Some companies are hiding their fees by inflating the exchange rate against what is called mid-market rate or fair rate. It’s entirely possible to give customers rate even below the mid-market rate if you can create direct partnerships with the banks and other currency sellers and buy the currency in large quantities.

Customers want better exchange rates, lower fees, faster service. They are reluctant to try the new service unless they heard about it from multiple sources family and friends, online, TV and newspapers. Which is understandable because trust plays the deciding role in the customers’ decisions to try or skip the service. This means huge marketing expenses for the money transfer companies and insane cost per acquisition (CPA) that doesn’t correlate well with customer lifetime value (LTV). Most companies are making money on fees per transaction but the problem is most customers don’t send money on a regular basis it’s not like SAAS app where users are predictably paying monthly subscription fee – maybe bimonthly maybe once every few months.

It’s tough to create an ideal UX for the customers as money transfer process involves filling out a lot of forms and information. The underlying money transfer technologies often don’t provide reliable way to track status of the transaction, which usually leads to lots of customer’s complaints about the delays. There are also regulatory compliance where the company should obtain a remittance license in every country it operates and implement a set of anti-money laundering and anti-fraud requirements such as Know Your Customer and Anti-Money Laundering.

Conclusion
Money transfer startups require a lot of funding to support its marketing and brand recognition efforts; to be become really successful they need to invest in their own technology and infrastructure. From the business point of view, the small players are not going to survive in a highly competitive/high expense market where market share directly relates to revenue and profits.

How to do estimates in product management

product management estimatesHow would you estimate how long will it take to have build something, an app or a website? It’s easy to do the estimates based on historical data – if you’ve done already something similar before a few times. However, if you are building something not done previously it’s relatively hard to do the estimates.

Software estimation is very hard because often developers work on unique features and functionality. Then there’s collaboration within the team and often code changes in one area influence other areas as well.

Velocity is used to do pretty accurate estimates. Before starting the sprint, you do the sprint-planning meeting. Let say you have 7 user stories in the sprint. You’re not asking the engineers how long each one will take. You ask the engineers how hard is each story in terms of story points. There are different scales for this but as an example – 1 is the easiest, 2 medium and 3 the hardest.

After each story has a number assigned to it by the dev team, all the points are added and now your sprint has the total story points per sprint. At the end of the sprint, you see how many story points developers were actually able to complete. Velocity equals the sum of story points of each story finished per sprint. Usually each sprint equals to 2 weeks period. So for example if the team were able to complete 2 hard 3point stories, 3 medium 2 point stories and 2 easy 1 point ones, the velocity will be 14 points.

To predict the team performance more accurately and do the estimates better you use average sprint velocity that is average of 3 or more last sprints. So now, you see how much work can be done over a particular period of time (2weeks) in terms of story points. Now if you have an story points estimate from the dev team and you have past average velocity you can pretty accurately predict what time will take to ship specific feature or functionality.

Product Management Roadmaps

product roadmapRoadmap provides an overview how the product develops over time and adds new features and functionality. To build a roadmap Product Manager considers business requirements, market trends and engineering constraints. Once the roadmap created, it should be shared with the team so everyone is on the same page, ideally online so if there’s any changes the team will get the updates.

Roadmaps in agile environment are very inaccurate because you can’t predict 3-5 months in advance what’s going to happen. You’re prioritizing the most important issues to work on next but it’s difficult to say how much time will it take. On the other hand, maybe something else (feature or bug) will take over and this won’t be a priority any longer.

It’s ok to have quarterly product roadmaps as a general guide. The roadmap might be accurate as a general guide but it won’t be accurate to the day it says on the roadmap. Moreover, if it’s accurate then you’re not being agile.

So, why then most product roadmaps are aligned along the quarters? Executives and investors like the quarter based roadmaps. The stuff in the 3rd quarter won’t be accurate at all because we’re agile. Sometimes you can have actual hard deadline especially in enterprise B2B environment for large companies. They have commitment from clients and investors to ship certain features or functionality by certain point. Sales can rely on releasing of the specific feature that is not being built yet too.

What could be an alternative to product management roadmaps? More appropriate or agile way is just sorting things out by priorities or three bucket model: immediate bucket – here’s what we’re doing now, midterm – what we’re doing next, and another column – long term – what’s planned for the future. This feature prioritization intentionally leaves the dates out of the picture. Large companies such as Facebook and Google commonly use it in B2C segment. They don’t have to release certain product by certain dates. It keeps things inline by not expecting releases by a certain date.