In the past few weeks we’ve been discussing Agile methodology to iteratively develop custom software that better meets the need of our customers. Probably more important than this concept, however, is to to define the business need before we ever begin a project. The way we accomplish this is by creating user stories.
Every software developer who utilizes user stories probably treats them a bit differently, but at Entrance, a user story goes something like this:
As a <role>, I want <to use xyz> to accomplish a <business goal>. I will consider this project a success <when>.
As an example, let’s say an oil and gas company wants to create a portal to unify their database and systems across departments. There are a number of different users for this portal, so the user stories are different. I’ll go through stories for a sales person, an engineer and a lab tech.
“As a sales person, I want to use my tablet to enter sales orders, sign clients and meet my quota. I will consider this project a success when I can enter a full order and confirm it, all on the tablet.”
“As an engineer using the engineering portion of the portal, I want to be able to report on oil production and well treatments. I will consider this project a success when I can generate a report in chart-specific format.”
“As a lab tech, I want to enter results from well samples into the portal. I will consider this project a success when I can report out to the engineering department and assign values to a specific well.”
You can see from these user stories that the same portal will be used to accomplish a number of different goals. There will be different measures of success. And if the developer of this portal doesn’t take this range of needs into account, the final product simply can’t be a success.
For more on how custom software can save your company time and improve process efficiency, check out this post. Or for some thoughts on how to decide whether to buy or build software to meet your business need, this checklist should help.