It’s Envoc’s job to make sure you have a great experience in every phase of your project. One of the most important aspects of that is how well we communicate. You may not know it, but software developers and designers have their own vocabulary for the processes and technologies used throughout the life of a project. So, to help you understand that language and ensure we are always on the same page, we’ve compiled the Envoc Agile Glossary to help guide you through the terminology you’ll hear throughout your project.
ACCEPTANCE CRITERIA
When writing a user story, you’ll help us define the Acceptance Criteria. These are the things that will determine the completeness and success in implementation of a user story. For example, if the user story states, “As an Administrator, I need the ability to log into the portal.” We’d define Acceptance Criteria as, “User must enter correct username and password to be properly validated and admitted into the portal.”
Our User Story defined the desired action. The Acceptance Criteria defined the parameters of success for the action.
AGILE
Agile is an iterative approach to software development defined by building software incrementally from the start of the project, instead of trying to deliver it all at once near the end. The focus with this approach is delivering high-quality, high-value code as soon as possible. What this means is that at Envoc, we (you and us) determine what code Envoc is going to work on for a two week period – then we develop it – then we show it to you in two weeks – then we (you and us) determine what we are going to develop the next two weeks. We don’t spend months writing documentation to define the software only to build the entire solution without your input.
BACK-END DEVELOPMENT
This is the portion of development that affects and determines storage, processes, business rules, and product intelligence. It is the non-viewable portion of the software. If we use a car as an analogy, it is the engine, transmission, axle, etc….things the user doesn’t see, but that makes the car go.
BASELINE USER STORY
When estimating the effort to complete a User Story, we first have to define a point of reference for that estimate. This is where a Baseline User Story comes into play. As a team, we define a User Story that is a conceptualized effort of 1. From there, we use that point of reference to define the difficulty of all User Stories for the project.
BURNDOWN CHART
This is a simple line graph that your Project Manager will use to estimate the end date for your project. It is based on your Product Backlog of Story Points compared to the Velocity your team is moving. So, for example, if your project has a remaining backlog of 100 Story Points and your team has a Velocity of 20 Story Points per iteration (usually 2 weeks), then your Project Manager can estimate that your project will finish in 5 iterations (10 weeks).
CONE OF UNCERTAINTY
When a software project starts, 30 years of studies have shown that the initial estimate of effort can vary by as much as 4x more or less because neither the estimator nor the client has fully defined the scope of the project. This potential variance in effort represents the Cone of Uncertainty. However, as we work through the project and know more and more about the scope of the project, our estimates will get better and better, reducing the uncertainty.
Envoc uses Agile Development as opposed to the old “waterfall” method. By using Agile, we tackle some of the bigger unknowns first and reduce the cone faster than is possible with waterfall. This allows us to provide more accurate estimates sooner.
Just for a reference, you’re probably used to seeing a cone of uncertainty, used with a different subject matter. Especially if you live on the Gulf/East Coast.
DESIGN COMP
After the functionality of your User Interface is defined, it’s time to make it pretty. Our Designers will take the wireframes we created and apply color, shading, textures, and pictures to create a work of art! These comps will be the basis for developing the actual working User Interface.
EPIC
An Epic is defined as multiple User Stories that are combined/grouped to represent a large feature or section of the project.
FRONT-END DEVELOPMENT
This is the portion of development that affects and determines the product UI. It is the viewable portion of the software. If we use a car as an analogy, it is the seats, steering wheel, body, etc….things the user sees and interacts with.
ITERATION
An iteration is a 1 to 4 week development cycle with defined project deliverables. For Envoc, we prefer 2 week iterations. Iterations are also additive in nature. That means, after one iteration, we might have basic functionality developed, and each week, as we use the product and you use the product, we refine it further and further. With this approach, you get to touch, see and feel your product early and often.
MINIMUM VIABLE PRODUCT
A product with the smallest amount of features that can still be released into production and provide value. By using an Agile approach to development, Envoc can get to your “MVP” much sooner than with a waterfall development approach.
PRODUCT ADVOCATE
This is you! You are essential to your project with us. As the Product Advocate, you are an authorized decision maker on the project. Your responsibilities include:
Attending all project iteration meetings
Managing the client effort throughout the life of the project
Helping to write and approve User Stories
Reviewing and providing timely feedback on Wireframes, Design Comps, and Development progress
Prioritizing User Stories for development
Helping to write and approving Acceptance Criteria
Accepting the finished product/features for release into production
PRODUCT BACKLOG
The Product Backlog is the total list of remaining User Stories and their associated User Points for your project. They are ordered based on priorities determined by you, the client.
SPIKE (or DEVELOPMENT SPIKE)
Occasionally we have clients ask us to estimate or execute something that has a lot of unknowns. In that situation, we may engage in a Spike. A Spike is a small set of predetermined hours that allows the developer to investigate the feature or product more fully to provide a solution, identify or mitigate risks, or provide a more accurate estimate.
STORY POINT
A unit of measurement that describes the estimated amount of effort or complexity a User Story will require to develop. Story Points are based off a Baseline User Story determined by the project team. Your project team will assign Story Point units to each User Story written for the project. This will help give the Project Manager and you an indication of complexity of the project/task and the time necessary to execute it.
TIME & MATERIALS ENGAGEMENT
This is a type of engagement that we offer to our clients. With this type of agreement, we will invoice you twice a month and only for the time used for your project during those time periods.
UI
Short for User Interface, the UI is the visible and interactive portion of the software.
USER STORY
This is how we’ll define your product. A User Story follows simple template/pattern:
As a [role], I need to [action] in order to [benefit].
By using this template, in a simple and succinct sentence, we’re able to define what the system or product should do all while explaining the value of that action. So, for example:
As an Administrator, I need the ability to disable user accounts in order to control access to the system.
VELOCITY
This is a representation of how fast we can provide deliverables. More specifically, it is the average amount of Story Points, and therefore User Stories, a team can complete in an iteration.
WIREFRAME
This is a simple, grayscale blueprint of the UI. It is not meant to show design elements, only navigation and layout. It allows you and your team to further discuss and define the actions of the user on the screen without any distraction from design elements.
