Category Archives: Analysis and Design

A Waterfall Analyst in an Agile World

business analystsHello fellow Salesforce Citizen Developers!

I’ve been working in some technology related function for most of my working life.  One of the key roles I have done is that of analyst.  Now analyst can mean different things to different people and even different things depending on the context of the work.  For this post think of an analyst as the person who helps the business clarify what needs to be done to meet a current business need.  In other words, analysts write requirements.

I know that some of you are cringing now with that simplistic definition but the point of this post is not to extol upon the definition of an analyst but to point out some key differences I have encountered regarding analysis work when working within a waterfall methodology and when working within an agile methodology.

Let’s first get some clarification around “waterfall methodology” and “agile methodology” in the context of this post.  In my experience what we call “waterfall” is basically defining everything waterfall-vs-agile2that the business needs or wants upfront, documenting in detail each item, developing the solution, testing the solution, deploying the solution.  You can think of a waterfall where at the top is the business saying what it needs and at the bottom splashing into the river below is the deployed solution.

As for “agile” the steps are similar but the work is done in small increments (called sprints) and pieces of the solution are delivered earlier than with waterfall methodology.  You also need, as I discovered, to unlearn some things you did in “waterfall” or the analysis work will bog down the agile process.

So what have I found that I needed to change to more effectively work within an Agile methodology?like-want-need

Create “Good Enough” Requirement Documentation

In Waterfall it is common to create a massive Business Requirements Document (BRD) that details every little thing.  You review it with your IT team and then walk away while they create a solution.

For Agile the business and tech work much more closely together so a doorstop of a document isn’t needed or, for that matter, wanted.  Instead the analyst should facilitate meetings between business and tech and talk through what needs to be solved and why.  The group then defines the requirements (stories) together at a level of detail that is good enough for everyone to be on the same page regarding the solution.

doco1Meet More, Document Less

I like to create documents.  There I said it!  I even used to be called the Doco Queen because I created some whopping huge and detailed Business Requirements Documents.  I also prefer to send all my fabulous documentation to folks to review instead of meeting. I have since learned that this is not the best way to get things done in an Agile way.

When you only have a sprint (typically 2 – 3 weeks) to get something defined, developed, tested and accepted you need everyone in the room and talking through each requirement.  Even for a team not located together, talking things through via phone, Skype, telepresence or some other mechanism, is preferable to reviewing documentation.  You need the give and take of a conversation to understand what the business needs and how you might go about building the solution.

So I have learned to document that basic requirement in the form of user stories and leave the details to the group sessions (typically called “grooming refinement sessions”).

Define What is a Successsuccess-criteria-1

To help everyone understand what “done” means regarding designing and building a solution, I have learned for each and every requirement the high importance of answering the question – “How do I know that this requirement has successfully met my business need?”

As an analyst this is an important part of the job when working with business partners.  Helping them to articulate what they would need to have/see/etc in order to consider what has been built to successfully meet their need.  This step can be hard for some folks but it is vital.

In Summary

So as a citizen developer I wear the analyst hat often and with great gusto.  I just need to remember to put on my Agile Analyst hat when I am working within an Agile world and define good enough requirements with only what’s needed documented including well defined criteria for success.

 

 

 

 

 

 

 

 

 

Focus on ‘Why’ instead of ‘How’

Knowing the how is necessary.  Understanding the why is illuminating.

Knowing how to perform a task is necessary.  Understanding why the task needs to be done can help you achieve a deeper understanding of the task and the process to which it is related.why what how

Knowing how to implement a solution in Salesforce is necessary but understanding why the solution is needed is much more important and illuminating.   Many times users will ask for changes based on their perception of how to fix the problem.  These changes sometimes address the immediate need but not the underlying problem that created the issue in the first place.  By asking users why they need a specific change, the analyst can get to the heart of the problem and help find the best solution to address the underlying problem so the issue will not happen again.

According to a new study in the Journal of Consumer Research, people who become focused on how to achieve a goal may have a harder time achieving their aims than people who think abstractly about why they want to do something.

Question

Can you share an example when knowing the ‘why’ helped with finding the best solution?

 

Good, Better, Best Requirements

I have gathered and documented thousands of requirements for hundreds of applications over
the years.  Good requirements are easily understood by the IT team and are testable.

I recently found a great post by David Shaffer called “It’s the clipboard2Requirements fault! A Recipe for Requirement Clarity “.  He really provides a clear concise method for developing solid requirements.  Below are a list of questions from his article that I highly recommend any analyst consider when gathering and documenting requirements.

For each requirement you ask the following questions:

  1. Is the requirement written in S-V-O format? (Subject-Verb-Object)
  2. Is the requirement written in active voice using a strong auxiliary verb?
  3. Does the requirement focus on the business need rather than a technical solution?
  4. Is the requirement easy to understand by all audiences?
  5. Is the requirement simple, short, and unambiguous?
  6. Will an example improve the understanding of the requirement?
  7. Will a visual figure or wireframe improve the understanding of the requirement?
  8. Can the requirement be tested?
  9. Does the requirement contradict any other requirement?
  10. Does the requirement describe how it must be implemented (Ex: display in alphabetic order, ascending/descending order, required/optional field, alphanumeric, numeric, etc.)

Question

What are some questions you normally use when gathering requirements?

4 Types of Email Notifications

Emails are part of the business landscape so including them in your Salesforce applicationemail1 makes sense.  Designing the look of the email and its contents is important so that the emails provide users with the right information at the right time.

So what are some typical scenarios that result in email notifications?

  1. Acknowledgement – when a user submits a request, CASE, etc
  2. Status Update – providing user with status of request, CASE, etc
  3. Escalation – providing user with information on an escalation
  4. Information – providing user with information

Design Considerations for Salesforce Email Templates

Every email should include the following:

  • Reason person is receiving the email
  • ID / Link back to the Salesforce record which resulted in the notification (if appropriate)
  • Relevant information
  • Next Steps for person receiving the email (if any)
  • Next Steps for Company/Group (helps to set user expectations)
  • How to contact us

In the process of creating your templates consider the following:

  • Pick the appropriate email template type based on what your email recipients can handle and the level of layout control you require.
  • Maximize your subject line
    • Keep it concise but informative
    • For mobile recipients some researchers feel the first 35 characters are key
  • Use Merge Fields to personalize content
    • Be sure the merge fields you will be using have data. The merge field will not appear in the email for a record where there is no data in that field.
    • Email templates give you access only to the fields that are accessible to you via your page layout and field-level security settings.
  • Configure your email Deliverability Settings — Information about these settings can be found here.

A great place to see how to create a Salesforce Email Template is the article “How to create an email template in Salesforce” at wikihow.com.

Question

How do you use email notifications in your business?