The Envoc Agile Glossary

Posted on November 12, 2015June 29, 2024 by Calvin Fabre

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.

User Experience vs. User Interface

Posted on March 11, 2015June 29, 2024 by admin

With the rise of User Interface design, there has been some confusion about the difference between it and User Experience design. Both are important when designing an application or website, but each brings a different aspect to the finished product.

User Interface: how the user and a computer system interact, particularly the use of input devices, visual controls, gestures, and software.¹

User Experience: the overall experience of a person using a product such as a website or computer application, especially in terms of how easy or pleasing it is to use.²

Many times, User Experience design is confused with User Interface design because of how closely they work together, so to explain both and the differences between the two, I’m going to tell a story.

The Journey to the Door

Once upon a time, there was a small town in the shadow of a mountain. The land was used up and desolate, so the people of the town had to travel to their neighboring towns to get food each week. This was a special town because in the mountain that shadowed the town was a door. This door was the entryway to a magical world that was rumored to have a magical power to grow things that were planted in the ground with a snap of a finger. Everyone wanted to explore the world but the door was high on the edge of a cliff and there was no path to get to the door. One day three people decided they would try everything they could to get to the door, so they gathered all their plans and ideas, and each began his or her journey to the door.

The first person decided to climb the mountain from the bottom up to the door, but on the first day had to turn back because he got a hole in his shoe.

The second person decided to take the long path on the far side of the mountain and repel down the cliff to the door. When he made it halfway down the cliff, he realized he didn’t pack enough rope so he had to turn back.

The third person decided to build a beautiful staircase up to the door so he could come and go as he needed, so he hired a team to come help him build his staircase to the door. When he made it through he found a place in the magical land to plant his garden. As soon as the seeds were planted – SNAP – all the seeds instantly grew into full plants covered with fruit and vegetables. The town rejoiced and never had to leave town for food again.

Journey to the Door: Explained

This is a story about the different experiences of three other people.

The first person never checked his gear, so he wasn’t prepared for the journey and had a bad experience.

The second person checked his gear but didn’t know how much rope he would need, so the gear was right, but his lack of planning negatively affected his experience.

The third person took his time and built a way to get to the top without interacting with the mountain. This provided a better experience not only for himself but also for anyone who wanted to get up to the door.

All three deserve credit for designing a trip; each had a user experience and developed a user interface to help them accomplish the journey. Two of them failed because the user interface (shoes, rope, etc.) didn’t fit the task at hand, which made them have a poor user experience and caused them to give up. The third not only considered the user interface (mountain, stairs, etc.) but considered the future users’ experience and came up with a good user experience for the town’s people to easily make the trip to the door without having to take long journeys each week.

Simply put, User Interfaces are the tools a person uses to accomplish a task or set of tasks, and User Experience is how a person feels when using those tools.

Wrap Up

Simply put, User Interfaces are the tools a person uses to accomplish a task or set of functions, and User Experience is how a person feels when using those tools. Based on this definition and the story, we can see that anyone can design a trip (an interface and an experience). However, only the design that accomplishes the goals and considers all aspects will let the user experience something magical.

Are you in need of the proverbial staircase to the magical door?

¹“Google Definitions: User Interface.” Google Search. 3 March, 2015.

²“Google Definitions: User Experience.” Google Search. 3 March, 2015.

Why We Don’t Offshore and Why You Shouldn’t Either

Posted on June 16, 2014June 29, 2024 by Calvin Fabre

Every week, we receive multiple calls from offshore companies offering software development services for as low as $11 an hour. Does the huge profit margin seem tempting? Maybe—but we turn them down every time. Here’s a few reasons why:

We Can’t Guarantee the Work

Envoc builds relationships with our clients and delivers experiences around design and software at an extremely high standard, every time. And while we can guarantee that standard for ourselves, we cannot guarantee it for anyone else working on a client’s project far, far, away. Envoceans are passionate, highly skilled, degreed, and/or licensed professionals with formal education and industry experience who have been vetted and continually trained. We know they are more than qualified to do the task at hand, so why would we trust someone else with our reputation and our client’s deliverables? We don’t and we won’t.

We Want to Sleep at Night

If you have not built a trusted relationship with someone, why would you trust them to build your bridges, provide air traffic control, write software that flies airplanes, process your payroll, or have access to your most valuable business trade secrets? Using outsourced resources increases security and privacy concerns while introducing anxiety and doubt. By using our own resources and knowing that our products are built the right way, we don’t have to worry about incurring Technical Debt or unforeseen legal issues. And we can sleep soundly as a result.

We Use Both Sides of our Brain

Much more right-brain work goes into creative services like branding, graphic and web design, user-interface design, quality assurance, and project management of software than just raw left-brained manpower for coding. Our Envoceans need and use the very best training, tools, and environment. Envoc invests heavily in training courses, materials, and conferences. We pay thousands of dollars each month for our legitimate software tools that are legally licensed, and we provide the very best collaborative and isolated work environments for our team and clients so that face-to-face meetings and secluded “zone-times” are as productive as possible.

We Don’t Pirate Software

Could we cut costs by pirating operating system software, development software licenses, and graphic assets? Could we pass on Professional Liability insurance and business taxes? We sure could, and many companies do to offer much better rates—but, again, we like to sleep at night knowing we are doing the right thing by our vendors and the great State of Louisiana in which we operate. Have you ever wondered how an offshore company can offer you a $15 per hour rate for software development? Do you have an idea why now?

We Speak the Language

When our clients tell us they want to “Put the Pedal to the Metal,” put a “Full Court Press” on a project, “Cover our Bases” or even “I want you all over this project like a Bad Perm” we know what their idioms and figures of speech mean and nothing is lost in translation. This may not always be the case when working with an overseas firm. Additionally, having 7:00pm conference calls during dinner time doesn’t help the home-life. As in a marriage, timing and communication is key. We like to think we are in a loving, committed relationship with our clients. Envoc’s definition of “Love” is “a commitment of our wills to the true good of our team and clients.”

Triage Available

Has your company or project been adversely affected by an outsourced or overseas engagement? If so, we would be happy to review the project and help you correct any critical issues or help you a plan to pay down the accrued technical debt. You can reserve a 30-minute appointment on Calvin’s schedule, by chatting with us, or by calling us at (225) 384-5549. We will personally triage your situation. If you want to keep the conversation to less than an hour, do not bring up politics or 80s hair bands.

Late: Technical Debt Interest Payment

Posted on February 21, 2011June 29, 2024 by Calvin Fabre

Your Technical Interest Payment is due.

If you have ever been involved in the development of something as simple as a Microsoft Excel macro, as normal as a public-facing website or portal, or been a part of a full-blown enterprise software application, you are most-probably guilty of ringing up “technical debt” which must be serviced. While national and state spending, deficits, and debts are the first things we hear about when we rise and shine, your technical debt may be accruing in quiet solitude.

What is Technical Debt?

“It is the extra effort technical people will need to make in the future in order to pay for quick-and-dirty design choices of the past.”

Who is responsible for this charge?

Remember the hot-shot programmer’s code that your team is constantly going back to fix? Remember the programming from the low-cost, overseas shop who didn’t code to your company standards, language or dialect? Remember the boss that “needed the project no matter what” who made you cut corners and who promised you could go back later and “do it right?”

Principle and Interest – Where is Dave Ramsey?

In this metaphor, “interest payments” are the countless fixes made and support calls taken to service the debt of a production system. With a large technical debt there is so much time spent “supporting and fixing” that there is no time for adding new features. If you think this frustrating, try getting approval from your client or boss for budget money or time to “go back” and improve the design by paying down some of the interest or principle. Be sure to explain that there will be no real difference the customer or user sees .

I thought some debt was good

One could argue that, in business, you might incur some debt to get to the market quickly, race to a trade show, or beat some deadline in order to grow your business. If you agree with this, you have to agree that very debt will someday come due. The same is true with technical debt – it will come due, with interest.

What can I do? I have Technical Debt!

With any problem, the first thing you need to do is acknowledge you have one.

Second, you need to include time and money in your budget for paying it down. How much depends upon how deep in debt you are. Third, set debt ceilings on future projects by committing to standards, procedures, and the absolute best people you can find. Lastly, manage your debt with periodic reviews logging them into a “debt backlog” and use a “debt snowball” to pay them down with any item over 90-days treated as “critical.”

Debt Assessment

You would not believe some of the projects we have been asked to fix for clients. To protect the guilty, we will not name names. We will however, give you a 30-minute, remote assessment of your technical debt and identify short and long-term risks. Why not schedule at 30-minute discussion with me, Calvin to see how we can help you? You can book me using this booking link. Or, give us a call at +1 225 384 5549.