How to use Readability Scores


Readability score resultsIf you need to make sure your writing is clear, the website Readability Score can help.

I’m not connected or affiliated to this website or its creator in any way, I just find it very useful, and wanted to share it with you.

Much of my working life involves writing, so to all intents and purposes I am a professional writer.

I want to show you why I find this site useful, and give you some recommendations on how to use it.

What is a readability score? What is a readability index?

The concept of a readability score (also known as a readability index) goes back many years, really hitting its stride in 1975, when Rudolf Flesch and J. Peter Kincaid built their Flesch–Kincaid readability tests for the US Navy.

The idea is that by looking at your writing, and making some calculations, we can figure out roughly how easy it is for somebody to understand what you’ve written.

It’s an automated calculation, so of course it’s not perfect, but it’s a very useful guide. The most common measures that these scores look at is sentence length, word length, number of syllables in your words, and the number of characters (letters) that you use.

Sometimes it’s difficult for a computer to count syllables accurately, so the measures are sometimes not 100% precise, but from a practical point of view that doesn’t matter.

There are two basic types of measures. The first is just a score, which doesn’t mean much by itself, but can be used to compare one piece of writing to another.

The second measure, which Flesch and Kincaid developed, and several others have followed, is more useful to us. It shows the average American school reading grade needed to understand your writing.

What are the most popular readability scores?

There are several readability tests that ultimately boil down to a US reading grade. This means that we can run several tests, compare them, and take the average.

Here are the big guns of the readability index world. They all work in different ways, and the links below take you to Wikipedia articles so you can find out more. They produce results of a US reading grade that are usually no more than two or three grades apart.

(Readability Score gives you these links when you see your results, which is nice.)

How does work?

This website was built and maintained by Dave Child, who’s based in the UK. I don’t know him personally, but he’s very friendly and responsive to email, if you have feature requests, etc.

The site is nice and easy to use, and looks good. You can either paste some text directly into the site (which is what I do), or upload files, or point the site to a URL web link that contains your text. The site can even monitor your links, such as your homepage, and alert you when certain readability thresholds are breached.

The results are very clear and easy to see, and I’m sure you’ll find it very useful.

You get to see the various reading grade levels for your writing, and an average.

You also get keyword density, ie how often certain words or two-word phrases appear. Personally I don’t need this, but if you write with SEO in mind it can be helpful.

Word count, sentence count, and average words per sentence are useful. I’ll give you some recommendations below for how you could use this.

The longest sentence is a crucial metric, and one that I asked the site author to add for me. (Impressively he added it within a day!) You also get the longest word, which can be helpful too.

If you are more than a casual user, there are very reasonably-priced subscription options, which help support the site.

A note on security and privacy: With sites like this, we always have to think about security and privacy. I’ve no idea whether this site (or any other similar site) stores your text, or does anything else with it. It probably doesn’t, but of course it could. (They do have a Privacy Policy.) So as always on the internet, it’s always best to assume the worst case scenario: don’t go pasting highly confidential documents into any kind of site like this, just to be safe!

How to use readability scores in your writing

Even highly intelligent and/or educated people (not always the same thing!) find it easier to read and comprehend writing that is at a lower reading grade. So no matter who you are writing for, whether it’s doctors and lawyers, manual workers, or the fabled “high-school dropouts”, a lower score is usually better.

The excellent book “Write everything right”, by Denny Hatch, (a long-time marketing man), is well worth a read. (Amazon UK  Amazon US)

It contains these facts from the Literacy Project Foundation, relating to American readers:

 50% of adults cannot read a book written at an 8th grade level

45 million are functionally illiterate and read below a 5th grade level

In other words, the average reading grade in America is 8th grade level. I have no particular reason to doubt that the UK is very similar.

The advice of Denny Hatch, which I agree with, is:

  • Keep sentences to 29 words or fewer
  • Write at 8th grade level or even lower if you can

Conclusion: an essential site for all writers

Here’s a screenshot showing the readability scores for this very article you’re reading now. (Click the image to see a larger version.) What do you reckon? Must try harder!

Readability score screenshot

Excel: How to find and count duplicate values in two lists

Use COUNTIF in Excel to quickly count how many values in one list appear in another.

I recently had a Master List of email addresses, and another list of Reject email addresses that needed to be excluded from this (because we no longer wanted to email these people).

Before I removed them from the mailing software, I wanted to see how many duplicates were in the list. (I didn’t want to accidentally wipe out the list by being over-zealous with the rejects!)

To do this, I used the COUNTIF function in Excel. (I’m using Excel 2016 for Mac, but this should work in any modern version of Excel.) This is much safer than a VLOOKUP for simple work. (See this article for the dangers of VLOOKUP.)

The screenshot below shows my spreadsheet. I replaced the email addresses with simple letters here, to make it clearer to see what’s going on.

Find duplicate values in Excel
Find duplicate values in Excel

I created three columns, for my Master List, my Reject List, and whether this row in the Reject List contains a duplicate.

The basic formula, as you can see in the screenshot below, is then:

COUNTIF(Master-List-Range, Row-From-Reject_List)

At the bottom I just did an Auto-sum. In this example, 3 rows are duplicates.


The Agile BA: Agile Business Analyst Course

I found a very good course for Agile Business Analysts, called The Agile BA.

As the homepage says, there’s 150 minutes of learning material (comprising 62 videos in 7 modules) and 30 quiz questions (with solutions) for self-assessment.

The course has a very good introduction to lean thinking, and the thought processes behind agile, which is a nice change from some educational materials and certifications that I’ve seen.

Business Analysts, project managers, developers, and business people who commission software would all benefit from understanding the material covered on this course.

It’s a shame it doesn’t count towards a recognised certification, but at $100 until the end of 2014 (and then $125) it’s very good value for money, and I recommend it to you.

The Agile BA

Fun and useful tools from Google that you might not have seen

Here’s a few genuinely useful things that you might not have realised you can do with Google.

Here’s the ones I think will be most useful or fun for you:

Set a timer, optionally full-screen: Just search for an amount of time, followed by the word timer, eg 25 minute timer (good if you’re a fan of the Pomodoro Technique!)

Google NGrams lets you see how usage of certain words in books has changed over time, from years 1500 – 2008.

See how to pronounce huge numbers by searching for the number and then typing =english, eg 1234567890=english produces “one billion two hundred thirty-four million five hundred sixty-seven thousand eight hundred ninety

Google Trends lets you see what the top searches are right now:

You can also enter a search into Google Trends to see how a search term has trended over time:

Google Trends Google Timer

Ten reasons to use a wiki for documentation

I’ve been very impressed by how useful the wiki has been in real world use: here are the reasons that have made the wiki very successful for us.

Thought Wikipedia was the only wiki? Think again! A wiki can be a great help in keeping all your documentation up-to-date and easily accessible. In this article I’ll explain why you should give a wiki a try.

For a couple of years now, I’ve been working with a FTSE 100 company that uses wiki software for keeping its internal IT documentation. This includes notes relating to development, testing, and how the various IT systems and business concepts work.

I’ve been very impressed by how useful the wiki has been in real world use, so I thought I’d share the reasons that have made the wiki very successful for us (and for me in particular, as a documentation author as well as a reader).

As knowledge management becomes ever more important, most companies should give serious consideration to using wiki software, not just within IT departments but in the wider business.

The wiki software I’ve been using is Atlassian Confluence, but no doubt using other wiki software will realise some if not all of these benefits.

So in no particular order, the benefits that I’ve personally found with using a wiki for documentation are:

1. Easy to find information

A wiki puts information is all in one place and is fully searchable.

With hundreds of topics, potentially written by hundreds of users, it’s easy to end up with a labyrinthine folder structure of Word documents that sit gathering virtual dust because nobody can find them. For example, I had been working with the company for about 8 months before somebody pointed me to some useful documentation that I could have used right from my first day with them!

A searchable wiki makes it quick to home in on exactly the information you require.

2. Easy to tell how up-to-date a document is

I recently read a corporate document, that’s still being issued, that discussed upcoming changes for 2005 – it’s now 2014 as I write this!

A wiki breaks a large topic into a series of sections, one per page, and with automatic date tracking for when each section was last updated you can easily say how up-to-date or out-of-date each individual section is.

If you read a sentence in the documentation similar to “John recently did some work on the payment system”, which is bad because it isn’t specific, you can at least roughly narrow down when this time period might have been. In a Word document that was started 10 years ago and periodically updated, you would have no idea as to even which year it might have been!

Since out-of-date documentation cannot be trusted, and might be either wrong or actively misleading, being able to tell the precise age of the documentation you are reading greatly helps with understanding how much or how little you can trust the documentation.

3. Easy to update, so gets updated more often

Updating the documentation is as simple as clicking the bookmark in your web browser to get to the wiki and making a few changes. There’s no need to fiddle around with version control or re-issuing documentation.

It’s also easy to do a very small change here and there, when you have time, and then build up the documentation over a period of time. I have wiki pages that I update probably once a week as I learn a new snippet of information. This contrasts with the approach of writing documentation into Word documents, where it feels more like you have to write a whole manual or definitive piece of documentation all in one go and then more formally distribute it.

So because wiki documentation is so easy to update, it tends to be more up to date.

4. Easy version control and roll back

A wiki lets you easily go back to a previous version of a page. You can take a more active approach to updating documentation, because you know you can never really break it, and can always roll back if you put the wrong thing in the wrong place.

5. No need for a single document owner

There are no bottlenecks centred around individual people for writing documentation or putting together everyone’s contributions. If you’re reading or reviewing documentation, and you know that something is wrong or out of date, you can update it immediately, without asking permission, and without waiting for somebody else. This helps to keep documentation up to date.

6. See who wrote what

Depending on who wrote the documentation (and your assessment of their competence!), you know more about the likely quality of the documentation, and exactly who to speak to if you have questions about it.

7. Links within the documentation to help users navigate

Being able to easily add links to other relevant sections of the documentation means it’s easier to guide readers to the precise areas of the documentation they will find more useful, and easier to make sure that the reader doesn’t miss other important topics related to the section they are currently reading.

8. See a list of recent edits to know who has been working on what

Atlassian Confluence has a dashboard view showing who has been editing what. It’s like a running commentary showing all the changes that have been made. It makes it easier to see who is working on what areas of the documentation.

9. Notification of changes

It’s easy to set up notifications for sections of the documentation that you are interested in, and then be told when those sections are updated. This way you can be made instantly aware of when important information might have changed.

10. Easy team collaboration for fast-moving information

For sections of the document relating to project status, or what will be released in an upcoming software release, where several authors may all be making changes in the same day, the wiki environment makes it very easy to make and share these changes.

When NOT to use a wiki

There are some downsides to using a wiki, largely relating to making sure that information is kept secure, but any documentation written down can theoretically be disclosed outside the company anyway, so this isn’t an issue solely related to wikis. Wikis can restrict access to certain pages to certain users anyway.

Wikis can tend to be quite free-form, with different authors doing things in different ways, so sometimes you need to try and impose a bit of structure.

If you need full distribution and approval controls, perhaps when issuing documents to third parties, then you might want to consider a fully-fledged Document Management System, but they are quite heavyweight and expensive, and you’re unlikely to really need it.


I’ve found that using a wiki for documentation brings the documentation to life. It’s no longer an old, stale and outdated document that gets written once and then forgotten about, never updated and never read. It keeps the information up to date, prominent, and searchable. I’ve been very impressed with using a wiki, so I recommend that you give it a try.

Action Points

If you want free wiki software then consider MediaWiki, which is what Wikipedia runs on. If you’d prefer a hosted wiki that you can get started with immediately, there are a variety of free and paid services.

How to interview a Business Analyst

As I see it, the primary aim of a job interview is to let the candidate prove his or her skills and show his or her ability to fit in with the team. You can then choose the best person for the job. Not everyone sees it like this!

If you’re not familiar with what a business analyst does, if we’re talking about producing software then it’s the business analyst who will understand the requirements for what the software should do, and will document this for the business people and the software developers. The business analyst acts as a bridge between the business and the technology.

A while back, when I was a candidate applying for roles as a contract Business Analyst, I went to two or three interviews before I found a role that I wanted to accept. I was struck by just how bad a job some of these companies were doing at interviewing Business Analysts. I also was very impressed by another company, whose offer I accepted, so I’ll talk about their Business Analyst interview process too.

Aims of interviewing a Business Analyst

First decide what your hiring process is aiming to achieve, then figure out a way to achieve it.

As I see it, the primary aim of a job interview is to let the candidate prove his or her skills and show his or her ability to fit in with the team. You can then choose the best person for the job.

Notice that I’m saying “prove” his or her skills, not merely talk about them. To my mind, you should be thinking more in terms of auditions than interviews. More of that later.

Competency-Based Interviews: the bad way to interview a Business Analyst

Let me fill you in on a horror story. I showed up for what turned out to be a Seriously Bad Interview. It was being run by two people; one seemed in some way to be connected with software development, but I wasn’t really sure what he did. He didn’t seem like he would be my manager though. The other person was from HR (Human Resources, Human Remains, you know the kind of thing.)

So straight away, you can see that at least one of the two interviewers, maybe both of them, doesn’t really understand the Business Analyst role, what a BA does, how it’s done, and what separates a good BA from a bad BA. Presumably the HR person was there for some kind of spurious compliance reason, to make sure some kind of obviously massively flawed process was being properly followed.

The type of interview was what in the jargon they call a “Competency-Based Interview”.

The questions were all of the form, “Give an example of a time where…”. And yet the scenarios were all so boring, so bland, and so commonplace that I seriously doubt that any candidate has ever given an interesting and illuminating answer that allows them to prove their skills. They were asking for the sort of things that you do all day every day, without really giving it a second thought, don’t tend to stick in the mind. “Give an example of a time you have held a pen.” It was that kind of moronic thing! No way to sort the wheat from the chaff.

There are two main problems with this kind of competency-based interview approach:

Problem #1: As a candidate, you really need to see the questions in advance to be able to think of interesting and enlightening scenarios that fit the question you’re being asked. Although tedious, some of the scenarios I was asked to give an example of were actually quite complicated. You’ve got about two seconds from when they ask the question to search your memory banks, combing through every day of your working life, to pluck out the most relevant and interesting scenario. That’s never going to happen! You’re probably just going to pick out the first thing that comes to mind. So even if the question tries to get at something interesting or useful to discuss, the candidate probably isn’t going to come up with the best example of that work on the spot, so as an interviewer you’re never going to see the best of them.

Problem #2: You’re likely to favour someone who talks a good game, even if they can’t actually do the job. As an interviewer asking questions, you’ll probably weed out the total fools who somehow slipped through the CV /resume screening process. That gets rid of maybe the bottom 50% of candidates. But of the remaining candidates, how do you know who’s best? You’ve got a base level of competence, but beyond that, it’s anyone’s guess as to how they’ll actually perform. If you were this kind of interviewer, and someone asked you “Are you 100% sure this person can do the job? What proof do you have?”, then you have to answer that no, you’re not sure, because you have no proof beyond the candidate’s assurances of their miraculous powers to analyse the business benefits of the water that they walk on! You haven’t proved anything!

The result: No candidate can possibly shine under this kind of amateurish questioning, and no interviewer can confidently identify the best candidate.

After this interview, I turned this role down. I reasoned that if the quality of the interviewing process was so poor, then the quality of the people I would be working with would probably be poor too, since there was no effective quality gate to identify the best people. Also, if this was the process that had been designed and rigorously followed (thanks to the HR policing), then whoever designed the process (and was likely to be in charge of something important) probably wasn’t much good either!

I hope whoever accepted the role is now enjoying it. (They won’t be.)

Case study interviews: The good way to interview a Business Analyst

The good company, whose contract role I accepted, decided to do an interview based around identifying requirements in a case study. The study was based on a real-world scenario that the company has actually faced, and then feeding back the requirements from this case study to the interview panel. The panel was made up of a senior business analyst, and also a senior software developer and project manager from the project the successful candidate would be working on.

I don’t want to say too much about the details of this exercise, since I’ve heard it’s still in use by that company and I don’t want to spoil its effectiveness for them.

There are some important lessons to learn from this approach:

  1. The case study approach isn’t just about talking the talk, you’ve actually got to do some work and prove your skills! Show, don’t tell, as they say in Hollywood!
  2. The case study simulates being able to work quickly and accurately under pressure.
  3. The interview panel has a senior business analyst, who understands the job, does the job himself, and knows what to look for. He’s not a generic HR person!
  4. The interview panel has people from the actual project that the candidate is being recruited for, so that the chemistry between the existing team and the candidate can be identified. The BA usually sits as a bridge between the development team, the project manager and the business, so it’s good to have multiple perspectives on the interviewing panel.

As a candidate, I felt that the case study approach let me demonstrate my analytical skills and my communication skills. It also let me slip in some facts and figures about the company I was being interviewed for, and their industry, to show I’d done my homework! (I’m always amazed by people who turn up to interviews without knowing anything about the company… and are surprised at how short the interview is for them!)

The case study approach was a much more effective way of simulating the real-life job than a competency-based list of half-remembered scenarios that happened several years ago!

During the time I was feeding back on the case study, I said various things that hinted at my previous experience, and along with the notes on my CV/resume this formed a second part of the interview, where the interview panel asked direct questions to get a feel for my level of experience on past projects in certain areas.


I’m sure there’s more than one way to effectively interview for the role of Business Analyst, and maybe a competency-based interview by a more skilled interview panel could be more useful, but a case study exercise, where the candidate proves their effectiveness with a real-world scenario, is a good place to start. When I was a software developer, interviewing other software developers, we used a technical test based on a computer programming exercise – a similar process with similar good results. It’s not a perfect process, but it definitely gets you a lot further than competency-based interviews! As a candidate, you can’t BS it, you can either prove you know your stuff or you can’t.

Action Points

If you’re interviewing someone for the role of Business Analyst:

  • Find a good case study based on some work you’ve actually already done, so that you know the points that a good candidate should pick up on.
  • Prepare a checklist of things the candidate should identify from the case study. Split the checklist into two: essential issues the candidate must identify, and secondary issues that give them bonus points.
  • Prepare two or three questions to give to the candidate that relate to the case study, asking them to identify and analyse the case study. Then you can talk about this during the interview and get them to verbally give you their findings, as they would in a project meeting.
  • Find an interview panel that represents the people the successful candidate will be working with.