How I am applying the Agile Methodology to non-technical business management activities at my own business. Filled with FREE consulting tidbits and insights learned from working at some of the largest technology companies in the world.

1. Applying Agile
Methodology to
Business
Management
How to get all your technical and
non-technical activities done with an agile
mindset
By Jose Vargas
linkedin.com/in/josebvargas/
@jvargas86

2. Agile Methodology
I have found that through minimal modification of agile processes, the methodology can be applied to non-technical business initiatives to
reap the same benefits seen in software development; greater utilization of resources and people, proactive stakeholder management, and
faster ROI.
While there are more complex forms of the agile methodology out there, make sure you are not killing yourself with unnecessary overhead.
At this time, I am sticking with the simple process I sketched out above and I have included notes for each stage of the process for both
technical and non-technical projects.
When in doubt, follow the law of simplicity that governs life itself. You start with a simple organism and as conditions change, the editing
process begins to adapt to the changes.
I have applied agile software development methodologies to speed up
delivery of product to market while also ensuring adequate analysis and
testing. The methodology allows for continuous delivery of MVPs (most
valuable product) set by the strategic goals of the business to realize return
on investment faster than the traditional waterfall method. While there are
other methods such as Extreme Programming and Joint Application
Development, in my experience they are not widely used in large corporations
and often the principles of these other methods can be included in Agile
development with demos, user stories from a variety of stakeholders, and an
EFFICIENT requirement change control process (easier said than done).
© Jose Vargas,
jvargas86@gmail.com

3. Epic Business Setup
Feature Legal Compliance
User Story Name Business License
As a Business Owner, I want to obtain a Business License so that I can
legally conduct business transactions with the public.
Acceptance Criteria:
1. Must be obtained prior to beginning operations
2. Must be issued by the appropriate government body and jurisdiction
3. A physical license needs to be obtained to be displayed at location
of business
4. All dues and fees must be paid to validate the license
5. EIN must be provided to comply with federal tax laws.
Sprint SP1-1
Estimate 6hrs
Type Business
Applying for a Business License Using Agile
I have recently thrown my hat in the entrepreneurial ring,
foregoing typical consulting gigs at large corporations in
order to gain perspective and a hands on education in small
business.
I will provide a simple example of how to apply the agile
methodology using my own experience in starting a new
business and utilizing the User Story process through the
SDLC.
I was now ready to document my first business
management activity of obtaining a business license.
* Here's a free tip that you won't have shell out big bucks
for a consultant: A good user story must also include
Acceptance Criteria or Definition of Done (DoD) that must
be proven during the testing phase. Without this, you risk
spending time and money on building something that will
not meet your business requirements and once you figure
this out, it will cost much more to fix it and delay release
of your product.
© Jose Vargas,
jvargas86@gmail.com

4. Applying for a Business License Using Agile
Using the agile method also forces one to set timelines,
estimates, and identify dependencies.
For this user story, I set 6 hours of work effort to take
into account filling out forms, transportation to and
from City Hall, and standing in line. This was important
for me include because it takes time away from other
activities. As I wait for the physical license to make its
way via snail mail, I have the ability to work on other
user stories so I did not include that in my estimate.
I included this story within a two week sprint that I
devoted solely to setting up my new company that
includes other user stories under different features
such as General Ledger (to setup my accounting books)
and Web Commerce (to obtain a domain and technology).
Related Tasks:
TK-1: Complete required forms. Since my small business will be based
in San Jose, I must apply either by mail or in person at…
TK-2: Pay all fees at the time of submitting all forms.
TK-3: Confirm receipt of physical license.
© Jose Vargas,
jvargas86@gmail.com

5. -Backlog Grooming-
This phase is a combination of ideation and planning. If you’re like me, ideas pop up at different times of the day often when I am not
working. The purpose of this phase is to write down your ideas as User Stories before you forget, even if it is just a title that you can build
out later.
★ Write down your ideas without worrying about where they fall into the user story hierarchy or if you have all the details (estimates,
acceptance criteria, etc.). Don't lose the creative momentum that your mind is in by getting lost in the details!
★ Schedule time to review and complete your user stories. This is where you add all the details you didn't have before. I like to do this
on a weekly basis sometimes more than once per week if I’ve had a really creative week.
★ ESTIMATE the amount of effort and working hours each user story will take. Depending on the length of your sprints you will need
to break them down into smaller stories (I prefer not to exceed 4 days). Ask for estimate input from your developer or external
vendor, lawyer, accountant, etc as needed.
★ By taking a look at your user stories, you will see that there are some that depend on the completion of others. Write down or link
them to each other so that you won't lose track of their dependencies.
★ Group dependent or related user stories together that you believe you can work on within the same sprint cycle. This should fill up
your dedicated working hours but make sure to leave at least a 10% buffer because unexpected things will come up and take time
away from your schedule.
★ I prefer 1-2 week sprint cycles to complete a set of user stories and do not plan more than one month at a time. We CANNOT
predict the future so save yourself the ANXIETY of trying to control it by planning too far ahead.
© Jose Vargas,
jvargas86@gmail.com

6. -Analysis & Design-
Begin working on a sprint that you planned out during the backlog grooming phase.
★ I researched how to obtain a business license in my jurisdiction and any additional legal requirements for which I can write other
user stories for.
★ Your user stories will likely require some up-front activities such as research, contacting others, hiring someone, or filling out
paperwork. This is your time to complete the activities that will ENABLE you to complete the user story per the Acceptance
Criteria.
★ If you find that the user story you are working on will require more time than you thought to complete or need to break it up to
smaller parts that you were unaware of before, don’t be afraid to throw it back into the backlog. Pick up another story that you can
squeeze into the remaining sprint cycle.
★ Review your acceptance criteria and add anything you may have forgotten.
★ COMMUNICATE - I cannot emphasize this enough- talk to your developer, cross teams, external workers, etc. to ensure they are
ready/willing/and able to complete the user story. Even you think this piece of work will not impact someone else, it likely will so save
yourself the headache and be open about your work.
★ For software related user stories, use this time to understand the technical requirements, create wireframes, and adjust any work
estimates provided by your developer or tech nerd.
© Jose Vargas,
jvargas86@gmail.com

7. -Development-
Time to roll up your sleeves and get to work on completing your user stories.
★ Execute the activities that will directly accomplish the Acceptance Criteria. Using my Business License example, this is where I
actually went to City Hall to apply for my license.
★ If your user story is non-technical, think about what may need to be documented such as process flows, training material, templates,
etc. You should be able to hand over these items and ask someone who has not worked on it to complete the new task or method of
doing something during the testing phase without any input from yourself.
★ For technical items, grab an energy drink and start coding. If you have a developer, let them go off and do their coding. This is their
art form and as artists, they have different methods of completing the job. Just make sure they keep you up to date and schedule
demos so you can see how things are going.
★ For large scale projects, code reviews, unit and integration testing are REQUIRED. This should be done PRIOR to the Testing phase
where product and user testing are executed (don't let someone with a fancy IT title convince you otherwise. You will end up eating
into your testing schedule).
★ If the work cannot be completed within the development cycle (again including code review/unit and SIT), the estimates you
provided during the backlog phase need improvement. Throw this user story back in the backlog and finish grooming it with new
estimates. Perhaps you also need to consider a longer sprint cycle depending on the complexity of your product or you need to break
up the work into smaller user stories.
© Jose Vargas,
jvargas86@gmail.com

8. -Test-
Using your acceptance criteria and other requirements try to break whatever it is you are building or understand why it will not be
successful.
★ I asked myself if there are any other license requirements for me for conducting business across state lines, hiring employees, etc.
★ I like to have the mindset that I am trying to prove why something will not work rather than prove why it will. I have seen many
things that should fail in testing pass anyway, often at the request of a manager who will never use the product or functionality
themselves.
★ For non-technical items, test your new process, templates, and any other new things you are introducing before completely
abandoning your old way of doing something. Notice how this impacts your productivity, schedule, and personal satisfaction.
★ For technical items, complete your QA testing, fix all bugs, and move on to user testing as quickly as possible. These SHOULD NOT
run in parallel, only when new bugs are found and QA retesting is needed for the fix specifically. Again, don’t let anyone tell you
otherwise.
★ If testing cannot be completed or if the product has failed the tests, don’t force it through. If you have time in your sprint,
continue the analysis/design/dev/test cycle until you get it right.
★ If this is the end of your sprint, remove the user stories related to the failed product from the sprint, save the work you have
completed, and go to your backlog grooming and slotting it into another sprint. This is easier said than done but your company culture
needs to accept failure as an outcome. It is not the end, you are doing this to build a better product.
★ If you work in an organization that seems to take a long time to deliver a product or requested functionality and you end up forcing
things through even if it hasn't been successful in testing, there are processes that need improvement up front. Testing is not the
issue.
© Jose Vargas,
jvargas86@gmail.com

9. -Evaluate & Improve-
You aren’t the smartest person in the world. There is always a better way of doing something so keep an eye on your product or whatever it
is the end result of your user story was and make improvements.
★ I created a new user story for the renewal of my business license to be completed prior to the expiration date.
★ Look at how your customers, end users, and relevant stakeholders are reacting to your product or other end result. Gather feedback
and write new user stories for added functionality that will improve their interaction.
★ Review the entire process you went through itself to reach your end goal. Is there too much overhead? Did any user story fall out
during a particular phase and why?
★ If you don’t like something about the process, product, or end result either improve it or stop doing it. If you don’t like it, no else
will.
© Jose Vargas,
jvargas86@gmail.com

10. The End.Happy managing!
Drop me a note if you have questions or comments!