Nobody wants their personal financial details, business information or photographs to be stolen or held to ransom, so simple things like using three or more words, a mixture of numbers, letters and symbols, upper and lower case letters will make it much more difficult for hackers to access your details.

Director of the National Crime Agency (NCA) National Cyber Crime Unit Jamie Saunders

The challenge is how to make a password sufficiently hard (if not impossible) to crack while at the same time making it easy enough for you to remember.

• Making it hard to crack - Use three random unrelated words as the basis of the password. Use a mixture of upper and lower case letters, as well as numbers and symbols. This increases of combination of characters used making it harder for a hacker to try each permutation when attempting to break your password.
• Making it easy to remember. Tips for creating memorable passwords include:
1. Location method - Imagine a familiar scene and place each item to be remembered in a particular location: glass on the table, sock on bed, photo on desk for example. Imagine yourself looking around the room in the required sequence. Re-imagine the scene and the location of each item when you need to remember the items. Use these items as the three words of your password. G!45550c<ph0t0
2. Acronyms - Use a phrase or a sentence and take the first letter from each word in that phrase or sentence to form your password. I want to remember this very strong password. !wtRtV5P
3. Narrative methods - Remember a sequence of key words by creating a story and littering it with memorable details e.g. ‘the ginger cat hissed at the big black rat in the sewer’ which can also be combined with the Acronyms method eg tGcH4tbbR!t5

It is vital to use a different password for each login. In reality this means using a password manager or a password vault application which allows you to remember one strong master password that you can use to encrypt, protect and access the others.

More advice is available at:

https://www.gov.uk/government/news/three-quarters-of-britons-risking-online-safety

https://www.cyberstreetwise.com/

The benefits of an Agile software development approach are well known. Agile invites change and refinement of scope throughout the lifecycle of a project to help organisations converge on the right product for clients. This is achieved through short iterations of development effort with frequent feedback during each iteration rather than a single big but often disappointing ‘ta-da’ at the end of the project. How then does Agile work in a fixed price contract where not only is price fixed but time and scope are fixed as well? Indeed, how do you estimate an Agile project to determine a realistic fixed price in the first place?

At first glance a fixed price contract implies a traditional waterfall approach, i.e. a tightly defined signed-off specification with no deviation on price, time or scope. This appears to be in tension with Agile which encourages change as an essential component of the process.  As we will see in this article it is possible to embrace change in a fixed price project by varying the scope.

To estimate a fixed price project in Agile you need to know the velocity of your Agile team in terms of story points, i.e how many user stories of what size and complexity the team can get through in a two week iteration or sprint. Estimates are measured in story points rather than in man hours. These are an arbitrary measure of the relatively size and complexity of user stories and are usually based on the Fibonacci sequence (1,2,3,5,8,13,21,34,55,89,144) or a Fibonacci-like sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) as this helps to emphasise the relative size and complexity of user stories in the product backlog. The bigger and more complex a user story, the higher the story points value. User stories are simply functional requirements expressed in terms that users and stakeholders in the business can understand for example – “As a Customer I can view and amend my online shopping basket.” This can then be broken down into smaller implementation tasks for a development team.

To estimate a project in terms of time you can use the formula:

Time = (total project story points / team velocity) * iteration length

So for example, if your team's velocity is 25 story points per two week iteration and the product backlog of user stories for the project has a total of 250 story points then we can estimate the time as:

Time = (250 / 25) * 2 = 20 weeks or 10 iterations or sprints.

Assuming a 7.5 hour day and a team of 5 and an hourly rate of £20 per hour we can estimate the cost of the project using the formula:

Cost = hours per iterations * number of iterations * people * hourly rate

So that …

Cost = 75 hours * 10 * 5 * £20 = £75,000

We have estimated the project will take 20 weeks and cost £75,000 so we are then in a better position to negotiate sensibly on the commercial aspects of the contract including any contingency and a margin for profit.

As the project progresses and changes emerge we can embrace this change in a number of ways. If the client changes their mind and wants another 20 story point user story added to the project then, because the project is fixed price and fixed time, this can only be achieved by removing another user story of equivalent story point value from the project.

Alternatively, where product backlog items can be given a MOSCOW priority then user stories prioritised as Shoulds and Coulds may be omitted if more time and effort is required for the Musts or new Musts are added due to new scope discovery during Sprints. In this way we can maintain the fixed price and deadline by adjusting scope. If all the product backlog items in the project are Musts and there is little room to manage scope in this way, then the client will need to make a difficult decision to remove Musts from scope risking viability of the product or they will need to agree to extend the project by the required number of iterations and provide additional funding.