Monday, 27 October 2014

Why fixed length sprints are important in Scrum

I have worked at several companies and on different projects doing Scrum. Some teams have been more disciplined than others in following the Scrum methodology.

In a few of these Scrum teams we have not adhered to the rule of a fixed sprint length, and the experience with that has always been negative. In this blog post I list reasons why variable or flexible sprint length is a bad idea.

Oh, and in case you wondered; fixed sprint length IS a well-documented best practice of Scrum [1], [2], [3], [4], [7], [8], [9].
Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened [1].
Sprints best have consistent durations.... A new Sprint starts immediately after the conclusion of the previous Sprint [1].

What typically happens in beginner Scrum teams or in teams where the Scrum master is busy doing other things than being the Scrum master is that they typically get into a situation where some stakeholder for example CTO, department manager or even the PO thinks it is a good idea to alter the length of the current sprint because that way you are able to finish a complete epic/module/product and have that released in one go.

The big problem with this is you easily fall into a slippery slope. Since you have extended the sprint a few days why can't we just extend it another day, and another day.

Another typical reason for not having a fixed sprint length is that resource availability will vary. So if there are vacations, bank days or you know some team members will be away you change the length of the sprint so that man-hours for each sprint stays about the same and you keep velocity the same.
For example; your team may decide that a sprint is always 15 work days. In practice you will then end up with different sprint lengths because resources availability will vary from sprint to sprint. Most people don't schedule and plan their entire vacation in detail many months ahead. That means that you will never know the exact availability of your team resources in the future. Also,you can predict how long a person will be gone if he breaks his leg in a car accident, but you can never know if or when a person will be in an accident in the first place. My point is that you can never know in advance how many calender days will match a fixed set of work days if you have decided a sprint should be a specific number of work days. Instead you should aim for a fixed length in calendar weeks, not work days. Calendar weeks are predictable, work days are not.  

Here is the full list of why you should stick to a fixed length sprint:

1. Improve coordination with the rest of the organization

It will be easier for everyone to know what kind of Sprint phase the team is in (e.g. planning, development, testing, reviewing). This predictability allows for better coordination and planning throughout the organization. The entire organization can sort of self-organize around this rhythm.

It also helps you to steer expectations. With a fixed length sprint everyone (PO, management, customers, users, and other stakeholders) will know when they can expect new upgrades (incremental improvements). They will know that a new upgrade typically comes every 3 weeks (or whatever your sprint length is).

2. Save time planning

With a fixed sprint length you can schedule and make plans more easily. A sprint is always the same length, that's it. Now you can schedule Scrum events for the next year ahead and you can do it in one go. You will have less overhead in planning because you don't have to negotiate what should be the sprint length each time, you don't have to make complicated man-days calculations and you don't have to change all the following sprints because you change the length of the current sprint.

Since you can schedule meetings in advance, people can plan their appointments around the Sprint events, rather than sprints being tweaked to fit the calendar of key team members or stakeholders.

3. Better quality

In general a fixed-length sprint will remove variability and this will lead to more predictability, stability, better flow, better and more sustainable work environment, less chaos. This of course leads to higher quality.

If you allow sprints to be shortened, say for example because the top management really want to have the next release earlier you not only loose rhythm but you will either have to work overtime, reduce quality, add more resources, or scope down the current sprint. If you scope down you waste resources and throw away planning/analysis that is already done and other work that has been started. If you decide not to scope down you are typically left with one option on such a short notice. You end up reducing quality for example by pressuring the testing to complete faster or by not letting developers do refactoring and other chores. If you decide to work overtime you still jeopardize quality since tired or pressured team members make more mistakes.

4. More effective work with better flow

With fixed length sprints it is much easier to get into a flow of doing all the Scrum related events such as backlog grooming, retrospectives, sprint reviews. With a predictable schedule you don't have to think about these events. When is the next meeting, will there even be one?

Without this fixed start and stop you may be tempted to move the start and stop date. You might even delay starting the next sprint long after the previous one ended. Beginner Scrum teams in this situation might not schedule the sprints for the months ahead but instead just start a new sprint when it makes sense. Before you know it you skip a retrospective and have to do sprint planning in the middle of a sprint. All this leads to more unpredictability, questions, chaos and less flow which eventually results in lower performance of the team.

5. Improve estimates

If the sprint length varies from sprint to sprint, then the amount of work accomplished in each sprint tells you next to nothing about what to expect in future sprints. Comparing how well you did on estimation in different sprints will be more difficult if you change multiple parameters of the process.

6. Enable continuous improvement 

Sprints can more easily be compared. In Scrum we try to fix as many parameters as possible; Time, Quality, Resources are fixed but we change the scope or work from sprint to sprint. By reducing the complexity down to just one adjustable parameter (scope / backlog) it will be easier to have discussions around opportunities for improving the process. The more variables you change the more complex the dynamics of the process will be and it will be much more difficult to compare sprints to improve the process. If you change multiple parameters around each sprint, how are you going to know for sure what actually contributed to things going better or worse?

7. Improve ability to predict when future features will be released

The organization or customer will know how long it will take to get new releases out the door if suddenly a new feature absolutely has to be introduced as soon as possible. E.g. If the team is in the middle of a sprint and the sprint length is 3 weeks it will take about 5 weeks to see the newly requested feature in production. If the sprint length is variable it would be far less obvious when you could expect the new feature.

For products planned several sprints down the road it would be even more unpredictable without a fixed length iteration.

Velocity (the rate at which a team delivers stories from the product backlog) is useful in forecasting when capabilities can be deployed and available to end users. Without fixed-length sprints, any measure of “work accomplished” is useless in forecasting. Alternatively you will have to make adjustments in the calculations of velocity based on the sprint length. These sorts of calculations become a waste of time as they are hard to get exact and just add extra work to the Scrum master. You can never hope to be 100% precise on task estimates so Velocity will never be exact science anyway. By having fixed length sprints you reduce one source or error in calculating velocity. Keep it simple, stay lean and pragmatic. Aim for predictability and simplicity and forecasting will be easier and less time consuming.

Sure there will always be holidays, sick days, etc. If a sprint has less resources you simply commit to less [5]. You calculate how many man hours is available and plan the scope accordingly. You may now say that this will affect velocity and number of storypoints delivered for these sprints will be lower. Yes and that is fine because you know the reason why. In the Velocity-over-time-graph you can just make a small note about vacation etc. when velocity had a dip. If you know most of the sprint is going to be all messed up because too many people are away you can also decide for the team to do something completely different. You could let developers take the sprint off doing courses, prototypes etc.

8. Improve team motivation

Fixed length sprint helps the team to deliver continuously and provides a sense of accomplishment at the end of every sprint. The team also commit to a chunk of work at the start of the sprint. The team gets motivated to deliver as they themselves committed to doing the work.

With fixed length sprints you have predictability and the team feels more at ease. People like to have routines and familiarity [5]. Fixed length sprints contribute to discipline, habits and traditions that creates team identity. "This is our team and this is how we do it." This again strengthens cohesion and team spirit, which is important for highly effective teams.

If Scrum events falls on random days of the week every sprint then it is hard to build good habits.

9. Accountability

Fixed length sprints with reviews at the end of the sprint encourages the team to deliver on the sprint review. Without a fixed sprint calendar the chance of skipping reviews gets much bigger. Without this regular review delivery the team may procrastinate, get caught up in coding what is fun rather than sticking to the plan or get distracted by other things. Developers don't want to look bad so they will deliver when it is demo time.

10. Better planning of backlog and roadmap

PO can better prioritize and split user stories now that meaningful data on velocity can be accumulated from sprint to sprint. PO can use this velocity as a guide to plan upcoming sprints.

11. Essential for multi team synchronization and alignment

When you scale to multiple dev teams doing Scrum (co-located or not) contributing to the same solution or product, it is obvious that synchronizing the teams will be more effective [6].

If the different teams operate with different Sprint lengths it goes without saying that the teams will not be in sync.


Scrum is all about delivering software in regular intervals to enable fast feedback and to get a effective cadence for the team.
Variable Sprint lengths may seem like a good idea, especially in the short term, but in the long run it will be devastating to the progress of a team.

If you liked this blog post, you may also want to read Scrum Best Practices: Choosing the Right Sprint Length.



Sunday, 14 September 2014

40 most funny code comments ever

These are borrowed from and

Exception up = new Exception("Something is really wrong.");
throw up;  //ha ha

//When I wrote this, only God and I understood what I was doing
//Now, God only knows 

stop(); // Hammertime!

// sometimes I believe compiler ignores all my comments
// I dedicate all this code, all my work, to my wife, Darlene, who will 
// have to support me and our three children and the dog once it gets 
// released into the public.

// somedev1 -  6/7/02 Adding temporary tracking of Login screen
// somedev2 -  5/22/07 Temporary my ass

// drunk, fix later

// Magic. Do not touch.

#define TRUE FALSE
//Happy debugging suckers
// I'm sorry.
return 1; # returns 1
Catch (Exception e) {
 //who cares?


 * You may think you know what the following code does.
 * But you dont. Trust me.
 * Fiddle with it, and youll spend many a sleepless
 * night cursing the moment you thought youd be clever
 * enough to "optimize" the code below.
 * Now close this file and go play with something else.

try {

} finally { // should never happen 

const int TEN=10; // As if the value of 10 will fluctuate... 

//This code sucks, you know it and I know it.  
//Move on and call me an idiot later.
double penetration; // ouch, no cumments needed

/////////////////////////////////////// this is a well commented line
// I don't know why I need this, but it stops the people being upside-down 
x = -x;

// I am not sure if we need this, but too scared to delete.;  // ... "a doo run run".


# To understand recursion, see the bottom of this file 
At the bottom of the file:
# To understand recursion, see the top of this file

// I am not responsible of this code.
// They made me write it, against my will.
/* I did this the other way */

/* Please work */
// no comments for you
// it was hard to write
// so it should be hard to read

options.BatchSize = 300; //Madness? THIS IS SPARTA!

// I have to find a better job
# code below replaces code above - any problems?
# yeah, it doesn't fucking work.

class Act //That's me!!!
public boolean isDirty() {
    //Why do you always go out and
    return dirty;

Until (JesusChristsReturn) ' Not sure

// Catching exceptions is for communists

// If this code works, it was written by Paul DiLascia. If not, I don't know
// who wrote it

//this formula is right, work out the math yourself if you don't believe me

// Comment this later

/** Logger */
private Logger logger = Logger.getLogger();

// Remove this if you wanna be fired

# This is becoz you messed with me the other day
if == "#{my_x_employer}"
  sleep(1000 * 3600)

# Linux Sex
$ date ; unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep

// Peter wrote this, nobody knows what it does, don't change it!

}catch(Exception ex){
   // Houston, we have a problem

// If I from the future read this I’ll back in time and kill myself.

// TODO: I believe the method (and all class in general)
// doesn’t make any sense at all, but I’m sleepy and
// it works fine

// A function that retrieves all females from the database
// for processing and display:
function getGirls() { //if only it were really that simple

float boat;   // must be a float, otherwise it sinks.

// I can’t divide with zero, so I have to divide with something very similar 
result = number / 0.00000000000001.

// no comments for you
// it was hard to write
// so it should be hard to read

Friday, 23 May 2014

Value cannot be null. Parameter name: s solution

I recently worked on a project where we were getting the error message below in our log files. This mysterious issue plagued us for weeks and we did not understand why we were getting the error and even how it impacted the user. We only knew that it would come in about 1 of 300 page views.

We were using a custom PageStatePersister and saving Asp.Net Web Forms Viewstate to a database. The error never showed up in the development environment.

We tried all sorts of things to reproduce it and make it go away. After some time trying to reproduce the error we managed to reliably reproduce it locally by doing simultaneous page requests for different web pages. Any request type async/non-async, postback/non-postback would trigger it. For end users it would manifest itself as annoying glitches or hiccups with possible loss of input data.

We finally managed to also locate the error after days of changing one by one line of code back to an older version.

The error was caused by someone having redefined the LosFormatter variable as static in our PageStatePersister.

Changing the LosFormatter variable definition to non static immediately solved the problem and also improved performance.

Exception type: System.ArgumentNullException

Value cannot be null.
Parameter name: s

   at System.Web.UI.ObjectStateFormatter.DeserializeIndexedString(SerializerBinaryReader reader, Byte token)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.DeserializeValue(SerializerBinaryReader reader)
   at System.Web.UI.ObjectStateFormatter.Deserialize(Stream inputStream)

Monday, 31 March 2014

Dji Naza flyaway air crash investigation

I love my Quadcopter but some weeks ago I started to loose control of the drone multicopter for unexplainable reasons.

Dji has gotten a lot of complaints in the last 6 months from what is often called fly-aways or more humorously called the “Fly to China” feature, (“Fly to home” is a highly regarded safety feature of the Naza M flight controller).

Many of these fly aways are simply pilot errors. There are a lot of pilots out there that should not be flying UAV's in populated areas. Still, reports by experts are plentiful so the problem is real, and serious. A serious accident is bound to happen from a flyaway if the problem is not solved soon.
Many quadcopter forums (such as rcgroupsdjiguys, ausrc, phantompilots, multirotorsforum, fpvlab) have discussed the issue and there are plenty of YouTube videos documenting live flyaways. Even so, Dji seem to be unable to address the issue. They have posted a video with some tips and released a firmware upgrade but the problem remains.

If you have experienced a flyaway please join this survey:

Suggested solutions to the problem can be found all over the place. Here are some solutions found elsewhere (Not my recommendations, just added to show the variety of solution proposals from others):
  • Don’t buy Dji products.
  • Don’t put it in GPS mode.
  • Put tape around the edge of the GPS.
  • Don’t fly when the sun is low in the horizon.
  • Don't fly too close to power lines and cell towers.
  • Reduce vibrations on the bird.
  • Adjust flight mode switch/FS setup (flight mode can jump back and forth due to the control PWM signal being right on the edge).
  • Make sure IOC mode is set up properly and not mistakenly activated/deactivated.
  • Check for loose double side tape on FC or GPS.
  • Replace the GPS/Mag if damaged in crash.
  • Remove FPV Vtx, it may interface with GPS signals.
  • Keep the compass/gps puck and cable away from power leads and battery.
  • Simple shielding on all NAZA inputs to protect data integrity.
  • Remove corrosion and oxidisation of pins and push-connectors.
  • Place Naza FC as close as possible to the center of gravity.
  • Power cycle after compass calibration.
  • Avoid large stick inputs.
  • Recalibrate the compass yet again.
  • Don’t fly when solar activity is high.
  • Make sure the ESCs travel midpoint is at 1520us. Do not use 700us travel midpoint ESC.

As you can see there are several suggestions for how to prevent flyaways, but no one seem to know exactly why it is happening in the first place. It might just be a combination of many things but I would still like to pinpoint the cause of this issue as I have experienced it myself and it is getting both dangerous and expensive.

I am also open for suggestions for how to improve the questionnaire.

My first flyaway (450 quadcopter with gimbal gone haywire) can be seen at the end of this video.

How to gain control if you experience a fly away.

If you have started to experience flyaways you may try to debug the issue by buying the Dji iOSD module to log data.
Another approach is to try systematically changing one thing at a time (environmental condition, copter config, copter parts etc) and see if the fly-aways stop. During this testing create an anchor; a 2 meter long line attached to the ground and tied to the bottom center of your copter.

You may also want to put your name and phone number on your multicopter in case of a flyaway or just not finding it after a crash.

Wednesday, 26 March 2014

Benefits of a schema-less database

A typical argument for choosing a NoSql database (such as a document store or graph database) over a relational database (such as MySql) is that NoSql databases are schemaless and that makes you more agile.

So, what does this actually mean? What are the concrete benefits of being schema-less and how does it actually make you more agile as a developer or as an organization?

In this context we use the term agile not strictly as in Agile software development but more in term of just being faster, more flexible, nimble and adaptable to change.

Here are some of the real world reasons why schemaless makes you more agile:
  • When starting a new development project you don't need to spend the same amount of time on up-front design of the schema (which is likely to change several times anyway). Less need for planning -> more agile.  
  • Once the NoSql is up and running the developer does not need to know about the database. No need to learn SQL or database specific stuff and tools. Less to know about. Less to learn for new developers -> faster development -> more agile.
  • The rigid schema of a relational database (RDBMS) means you have to absolutely follow the schema. It can be harder to push data into the DB as it has to perfectly fit the schema. Being able to add data directly without having to tweak it to match the schema can save you time-> more agile.
  • Minor changes to the model and you will have to change both your code and the schema in the DBMS. No schema -> don't have to make changes in two places -> Less time consuming -> more agile.
  • With a NoSql DB you have fewer ways to pull the data out -> fewer ways to shoot yourself in the foot -> less chance of being bogged down in problems later (e.g. as unforeseen intricate future queries starts to manifest themselves as performance issues) -> more agile.
  • Schema-less -> Less overhead for DB engine -> better performance and scalability -> Less overhead for developers related to scalability -> Fewer devopment obstacles -> more agile. 
  • Changes to the DB schema will often break the solution for other developers and they have to keep updating the DB schema locally even if they are working on something completely unrelated. Syncing DB and code as you pull from your source code repository requires extra work and sometime even extra time trying to figure out why your solution don’t work after Git pull. No schema -> Fewer problems with code/schema not being in sync -> More agile development.
  • ALTER TABLE operations during deployment can be very heavy on the system and will usually result in downtime. Schema changes in general will break the system when code and schema is not in sync during deployment. No schema -> less downtime -> deploy whenever you like-> more agile.
  • Save time when the day comes when you have to denormalize tables because of performance issues. Less overhead related to schema -> more agile.
  • You don't have to deal with artificial link-tables (for many to many relations) because it is built into graph databases. -> fewer things to deal with -> easier to modify code/"schema" -> faster development -> more agile.
  • Eliminates the need for Database administrators or database experts -> fewer people involved and less waiting on experts -> more agile.
  • Less time needed to pick the right datatypes for new database columns -> save time -> more agile.
  • Schema-less -> better DB engine performance -> less chance of having to create separate systems to offload the DB because of heavy queries from big reports etc. -> less complicated system -> more agile. 
  • Save time writing complex SQL joins -> more rapid development -> more agile.
  • Rolling back code doesn't necessarily break the App, you might just not get the data you expect. Easier to deploy/rollback without serious consequences -> more agile.
  • As more and more applications/systems use your RDBMS it is harder to change the schema because of dependencies. Change the schema and you might f* up some other system. With NoSql schema changes other systems might not get the expected data but the chance of runtime errors is less. No schema -> less worry about messing up for other systems -> more agile.
In this blog post I have covered only the benefits of schema-free. There are also drawbacks but for the sake of brevity it is not included here. Being super agile might not be the top prioritization for all organizations.

Wednesday, 5 March 2014

SPARQL and RDF introduction for technical persons

This is a quick introduction to SPARQL and RDF for developers. I believe SPARQL and RDF are such profound innovations that all IT-persons and developers should know about it. So here's me spreading the word.

In this blog post I will show some examples of basic SPARQL queries, but first a short intro to RDF.

Typical relational databases are organized into tables that look something like this:

Table: Persons
Id Name Date of birth Department Id
2 Roy Lachica 22.12.1975 5
4 John Doe 3.4.1973 6
Table: Departments
Id Name
5 Development
6 Human relations

In RDF this would be represented something like this:
subject predicate object 1975-12-22 1973-4-3

This could also be represented as a node graph.
In the example RDF data above we use URI's as identifiers instead of primary key ID columns that are used in relational databases. These URI's and their namespaces are predefined schemas typically defined by other organizations. This is where the big innovation lies.

The problem RDF solves 

In the relational database example we have manually defined the schema our self. There is no way for others to know what the columns mean. Although you might guess from looking at the data. If we were to expose the data through a REST API there is no way for the API consumers to be sure what the data mean, unless they read the documentation. The API consumer will manually have to couple properties, parse and transform data. In short, they will have to make sense of data and its structure.

The innovation

In the triplestore (RDF database) you can put anything in, you can change the data to whatever you like. This will make you more agile. You are not restricted as in a relational database development stack where you would have to change all the above layers if you make a change in the schema.

You also don't have to care about SQL and database engine quirks and performance issues when designing the schema. The extremely simple universal RDF model is a directed graph and you don't need to normalize, denormalize or setup indexes, keys, decide to use stored procedures or not etc. There is no notion of a NULL-value and this will reduce potential bugs.

In RDF, anyone (also computers, not just humans) can make sense of the data, as long as you use known RDF schemas. These schemas are also called vocabularies and ontologies (ontologies are just more advanced vocabularies). There are even some basic semantics inherent in RDF so for simple structures you might not even need to define or reuse a schema.
The URI's tells us what schemas are used and the schema is not hard-coded into the database but instead openly defined. (A schema could also be company internal but that would sort of defeat the purpose of enabling a global database or web of data through connecting disparate data sources)

SPARQL examples

RDF triplestores have SPARQL-endpoints for querying the data. Fortunately university of Mannheim have made such an endpoint openly available. This endpoint exposes a CIA world factbook example database.

The endpoint is located at:
Feel free to check out the endpoint and click around.

This endpoint (with a typical SPARQL user interface) lets you query the triplestore and return the results as JSON, XML or HTML for reading on screen.

You may also type in a query directly in your browser address bar:

Various SPARQL queries

Try copying these into the endpoint SPARQL textfield.

SELECT * WHERE { ?s ?p ?o} limit 10
This will get the first triples (subject-object-predicate set).

SELECT COUNT(*)  { ?s ?p ?o  }
Get number of triples in the database.

SELECT (COUNT(*) AS ?triples_count) { ?s ?p ?o  }
Same as above but with a name for the result, making the output more human readable.

SELECT DISTINCT ?value WHERE { db:Algeria ?value ?o}
Get all properties (the predicate part) of triples where Algeria is part of the triple.

SELECT DISTINCT ?value WHERE { db:Algeria factbook:climate ?value }
Gets the climate in Algeria.

SELECT DISTINCT *WHERE { db:Norway factbook:landboundary ?borderingcountry }
 ORDER BY ?borderingcountry
Get the countries that border to Norway.

SELECT DISTINCT ?country ?literacypercentage
  ?country factbook:literacy_totalpopulation ?literacypercentage .
   FILTER ( ?literacypercentage > 70 )
order by desc(?literacypercentage)
Get all countries with a literacy percentage over 70.

SELECT DISTINCT ?country ?literacypercentage ?populatoncount
  ?country factbook:literacy_totalpopulation ?literacypercentage .
  ?country factbook:population_total  ?populatoncount
   FILTER ( ?literacypercentage > 50 && ?populatoncount>5000000)
order by asc(?literacypercentage)
Get all countries with a literacy percentage over 50 and having a population count of more than 5 million. Sort results by countries with the lowest literacy on top.

SELECT ?country ?population ?growthrate ?capital_city ?area
?x  factbook:name ?country ;
factbook:population_total ?population ;
factbook:populationgrowthrate ?growthrate ;
factbook:capital_name ?capital_city ;
factbook:area_total ?area .
Get country name, population, growth rate, capital city and country area size of all countries.

Further reading

A Relational View of the Semantic Web

Tuesday, 14 January 2014

A simple requirements specification template for websites

If you are about to develop or hire someone to develop a new website you will need to articulate a set of requirements or needs for your coming website. In this blog post I will present a simple check list / template that can be used as a starting point. For more advanced high end sites you should go with a more in-depth process but the questions below might help you get started.

Visitor features

What should the visitors be able to do on this website? What kind of user interactions will the site have? Most importantly answer why. This should all be defined based on a content strategy / information strategy etc. What about multi-language support on content and the editor interface? What about features such as: contacts, events, press releases, product catalogue, webshop, automatic creation of PDF's such as reports, image gallery, videos, FAQ, user comments, forum, blog, wiki. Will there be specific needs concerning advanced content and design such as storytelling, copywriting, art direction etc.

Administration features

How will the website content be updated? Will there be any particular process for adding and modifying content? How many persons will be doing it, how often? How computer literate is this person who will be updating the content? Will you need to manage an online community associated with the website? In that case you might need a community manager, moderator etc.

Future site upgrades

Is it important that future developments to the site can be done by most development shops/consultants? If so state a requirement to use a commonly known CMS. Do we need any service level agreements for system changes to the site? Do we need support for the content editors? Do we need technical documentation on how the site is built? If there is a lot of advanced customization this might be a good idea.


Is it highly likely that the site will become very popular within a few years? If so consider SaaS, PaaS, cloud services etc. to help you cope with dynamic traffic demands. This is also relevant if you know the site will have extreme traffic spikes at specific times of the year.

Site structure and content

Create a hierarchical view of the pages that will be part of the site. This can simply be a document with level headings going from heading 1 to 4. You probably also want to provide multiple ways to your content by using tags or categories? Will there be user generated content and what is the extent? Will there be massive amounts of content? What is your unique selling proposition (USP)? How will your site stand out?

Logging and audit trail

Is it important to log things like who did what when with site content?

Key Performance Indicators 

Will the persons responsible for the website be followed up on KPI's? E.g. maybe the web team is required to create a new post each week? or maybe there is a requirement that the site should have a certain number of visitors or be on a list of top sites within a specific category?

Visitor tracking and reporting

You probably need to visitor statistics. Is Google Analytics fine?

Search Engine Optimization (SEO)

How high are our ambitions when it comes to being found on and ranked high on search engines?


Should people with special needs be able to use the site? How much support should they get? Should they just be able to read it or should you provide good user experience for this group? Should blind people be able to use the site?
Where should the site be available? What kind of devices? Old devices/browsers?


What kind of look, mood, style do we want? How do want to be perceived? Our values and mission has to fit the style. What level of design excellence should we strive for? Is it important that the readers find the site really good looking and appealing?


Do we need special considerations when it comes to security and permission control? Will different people need different access to some content? Will some editors need more permissions than others?
Is it extremely important that the site is not hacked? Hackers typically break site and put advertising and malware on hacked websites.


Is it important that the site is fast to load? Do we need the site to scale? will there be millions of visitors and will the traffic grow?

Server location

What about hosting? How will the website be hosted? In your country? Maybe you have compliance rules to follow when it comes to where the server is located? Do we have environmental concerns? Some hosting providers are more environmental than others. If most of your users come from the other side of the world then consider a server location in that region.


Is it important that the site is available at specific times. Do we need disaster recovery and service continuity? Extra redundancy and backup plans in case of atomic bombs wiping out your country? a bit extreme there but you get the point.

Other requirements 

Non functional and functional? Maybe we are required to use Open Source? Will there be a need for related services such as video editing, brand/identity design, design of advertisement banners. What about e-mail accounts?


Escrow? Budget? Time plan? Legal issues?