Sometimes our clients are pushed for time.  This time we had to conceptualise and launch an event website in under 14 days. We are proud to say we did it. It took us exaclty 11 days.. ok and nights. But we did it.

Monique’s Creative team has worked absurd hours round the clock to meet this incredibly tight deadline. The Developers have also shown what they are made of - and sprinted with the Ruby on Rails development manoeuvering around a few PayPal quirks along the way too.

We’re rpud to say- the client is delighted and we’re exhausted but happy!

Have a look and tell us what you think: http://CharmedLifeEvents.com

As Rory Cellan-Jones, BBC wrote yesterday (13 January, 2009), confirming our own observations, at least one line of business is absolutely recession-proof these days. Perhaps it is hard to believe it given the dot-boom experience of eight years ago, but it is e-commerce. Yes, e-commerce or e-tailing has finally come of age.  Nielsen Online [pdf], which puts web traffic under the microscope, reports that traffic to the top ten UK retail websites was up by 37% in the last quarter of 2008 compared to the previous year. 

“No surprise that Amazon is at the top of the list with a monthly audience of 15.6 million. But that was a rise of just 18% on the previous year, whereas the figures for some traditional retailers were far more spectacular. Argos saw its audience rise by 32%, Marks and Spencer had a 46% rise and Littlewoods’ audience was up 66%.”

As Rory Cellan-Jones says “Back in the late 90s the dotcom evangelists told us that online start-ups would crush the dinosaurs of retailing and leave the shopping malls and high streets deserted. That didn’t happen - but a decade later the online retail revolution is finally happening. And funnily enough, the dinosaurs are now leading the charge.”

Looks like the surest bet to survive, if not plainly thrive, in the times of recession is to seriously re-think one’s online strategy. After all websites turned out to be THE channel preferred by the savvy consumers of today.

On our part, Morango has launched no less than four new sites in the last 4 weeks, and is seeing a growing, if anything, demand for both e-commerce and general marketing websites.

———-

Morango is a London based creative agency specialising in web design and web development.

User Story is a software system requirement formulated as one or two sentences in the everyday or business language of the user. User stories are used under the Extreme Programming (XP) paradigm for the specification of requirements (together with acceptance tests) (XP). Each user story is limited, so it fits on a small paper note card — usually a 3×5 inches card — to ensure that it does not grow too large. The user stories should be written by the customers for a software project and are their main instrument to influence the development of the software.

User stories are a quick way of handling customer requirements without having to elaborate vast formalized requirement documents and without performing overloaded administrative tasks related to maintaining them. The intention with the user story is to be able to respond faster and with less overhead to rapidly changing real-world requirements.

But what are characteristics of a good story? The acronym “INVEST” can remind you that good stories are:

• I - Independent

• N - Negotiable

• V - Valuable

• E - Estimable

• S - Small

• T - Testable

Independent

Stories are easiest to work with if they are independent. That is, we’d like them to not overlap in concept, and we’d like to be able to schedule and implement them in any order.

We can’t always achieve this; once in a while we may say things like “3 points for the first report, then 1 point for each of the others.”
Negotiable… and Negotiated

A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we don’t need these to prioritize or schedule stories.
Valuable

A story needs to be valuable. We don’t care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive them as important.

This is especially an issue when splitting stories. Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer. When we split a story, we’re serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it “right”); but a full database layer (for example) has little value to the customer if there’s no presentation layer.

Making each slice valuable to the customer supports XP’s pay-as-you-go attitude toward infrastructure.
Estimable

A good story can be estimated. We don’t need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation. Being estimable is partly a function of being negotiated, as it’s hard to estimate a story we don’t understand. It is also a function of size: bigger stories are harder to estimate. Finally, it’s a function of the team: what’s easy to estimate will vary depending on the team’s experience. (Sometimes a team may have to split a story into a (time-boxed) “spike” that will give the team enough information to make a decent estimate, and the rest of the story that will actually implement the desired feature.)

Small

Good stories tend to be small. Stories typically represent at most a few person-weeks worth of work. (Some teams restrict them to a few person-days of work.) Above this size, and it seems to be too hard to know what’s in the story’s scope. Saying, “it would take me more than month” often implicitly adds, “as I don’t understand what-all it would entail.” Smaller stories tend to get more accurate estimates.

Story descriptions can be small too (and putting them on an index card helps make that happen). Alistair Cockburn described the cards as tokens promising a future conversation. Remember, the details can be elaborated through conversations with the customer.
Testable

A good story is testable. Writing a story card carries an implicit promise: “I understand what I want well enough that I could write a test for it.” Several teams have reported that by requiring customer tests before implementing a story, the team is more productive. “Testability” has always been a characteristic of good requirements; actually writing the tests early helps us know whether this goal is met.

If a customer doesn’t know how to test something, this may indicate that the story isn’t clear enough, or that it doesn’t reflect something valuable to them, or that the customer just needs help in testing.

A team can treat non-functional requirements (such as performance and usability) as things that need to be tested. Figure out how to operationalise these tests will help the team learn the true needs.

“Formal” User Stories

In User Stories Applied Mike Cohn suggests a more formal approach to writing user stories. He suggests the format:

As a (role) I want (something) so that (benefit).

For example, a user story of could be written as “As a Student I want to purchase a parking pass so that I can drive to school”. This approach helps you to think about who a certain feature is built for and why.

Source

This artifact description is excerpted from Chapter 5 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.

What is SCRUM?

is an iterative incremental process of software development commonly used with agile software development.

Best explained here: Scrum in five minutes

SCRUM Documents

Product backlog

The product backlog is a high-level document for the entire project. It contains broad descriptions of all required features, wish-list items, etc. It is the “What” that will be built. It is open and editable by anyone. It contains rough estimates, usually in days. This estimate helps the Product Owner to gauge the timeline and, to a limited extent, priority (e.g. if “add spellcheck” feature is estimated at 3 days vs 3 months, that may affect the Product Owner’s desire).

Sprint backlog

The sprint backlog is a greatly detailed document containing information about how the team is going to implement the requirements for the upcoming sprint. Tasks are broken down into hours with no task being more than 16 hours. If a task is greater than 16 hours, it should be broken down further. Tasks on the sprint backlog are never assigned, rather tasks are signed-up for by the team members as they like.

Burn down

The burn down chart is a publicly displayed chart showing the number of tasks remaining for the current sprint or the number of items on the sprint backlog. It should not be confused with an earned value chart. A burn down chart could be flat for most of the period covered by a sprint and yet the project could still be on schedule.

Useful Templates

Excel Spreadsheet

Useful Online Software

• Agilo42
• BananaScrum 

Useful Reading & Examples

http://en.wikipedia.org/wiki/Scrum_(development)
http://agilesoftwaredevelopment.com/system/files/SimpleProductBacklog.xls
http://agilesoftwaredevelopment.com/videos/scrum/simple-product-backlog (Video)

http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms

Here’s a humorous, but not far fetched breakdown by Alan Foreman of poisonedminds.com:

25 March 2008, London. Morango.co.uk are pleased to announce the launch of UKStaffSearch.com, UK’s newest recruitment portal. We’ve worked with the client since late December 2007 and we’re delighted to see the site go live and immediately get paying subscribers.

UKStaffSearch.com site is a custom build CakePHP eCommerce recruitment portal aiming to radically alter the UK recruitment market by introducing affordable source of high quality CVs to recruitment agencies and in-house recruiters.

We’ve worked closely with Jim Munday, the CEO of UKStaffSearch.com to implement and refine his vision.

Morango.co.uk is an independent web design & build agency. We’re passionate about bespoke, creative web solutions for SMEs backed by our thorough knowledge of the web and technology.

Before you start thinking what it should look like it’s a good idea to ask yourself what should it do? And Why? (more…)

1. Requirements Analysis

• Determine the goals for the website from the perspective of the user and the business.
• Define the user needs and target usability requirements.
• Evaluate existing versions of the site and of competitors/inspiration.
• Understand existing constraints

2. Conceptual Design

• Sketch out a site design and architecture at an abstract level.
• Conduct a task analysis to find critical features.

3. Mock-ups / Prototypes

• Create visual representations (mock-ups) or interactive representations (prototypes) of the site.
• Evaluate usability through user tests, and walkthroughs.
• Use the evaluation results to create more mock-ups or improve the prototypes.
• Repeat this step until the design and usability goals are met.

4. Architecture

• Determine the most appropriate technologies to achieve desired UI style and backend functionality
• Evaluate cost and time impact/effect of all such components.

5. Production

• Create the website pages
• Evaluate functionality through testing, quality assurance, usability testing, and field testing.
• Use the evaluation results to improve the product.
• Repeat this process (production iteration) until the business goals are met.

6. Launch and Maintenance

• Launch the website or section.
• Maintain and refine with user feedback.
• Use the feedback to create new requirements, and begin major design improvements.