Archives for

Taking a view on Agile requriements

December 2, 2010 by jmorse in agile, project management, scrum | Leave a comment

I have recently been having a discussion with a colleague trying to get them to understand that, in an agile environment you don’t need to define the deliverables with finite detail but instead have a vision of what you need to achieve and work towards it in measurable chunks.

In order to do so I used the metaphor of someone who, looking into the distance can see their immediate destination close up, they can see the fences that bar their way, or shortcuts that will save time and effort and can plan their route in detail.

However as they look further into the distance and towards their eventual destination, the detail to which they can plan their route gets less and less.  It’s only as they travel their route that they get to see the new barriers, new paths to tread and that they can plan the route for the the next phase in detail.

Have a view of the long term goals of your project but you can’t plan the whole thing in detail as things change was you go, plan the next phase in detail using your experience to make informed decisions, defining the detailed requirements for the each phase in turn refining your understanding of the project deliverables as you go.

And remember, the methodology is a tool to achieve the end goal not the goal itself.

Read More

Evolving sites – tech-volution

June 15, 2009 by jmorse in content, requirements, social networks, user interface, web 2.0 | Leave a comment

Reading Robert Scoble ‘s friend feed conversation list, he posted a notice that got some traffic regarding the use of twitter as a conversations tool

His argument was that twitter was not and should not be used as a tool for conversations, but more for ‘announcements’. Now his argument is not without merit, if you follow many followers or take your eye of your twitter app for a second then you can quickly lose the conversation thread, however he seems to be implying that you should not use twitter in this way, full stop. Problem with that is his argument suggests that there is a set if rules for using twitter and these should be followed by all users, this is wrong, for twitter and all other products or services being developed. There are no rules there are however behavious patterns that define how users adapt a service to their needs, and its this that makes the web(2.0?).

If twitter or any service is to survive then it has to evolve, just like people.

Argument is as follows:

As you build a site( for site you can substitute webapp /service /product/whatever but I’ll use app for ease of use) you have an idea of the users that you need to talk to. If your smart you talk to these users and ask them what they want, try to use this to identify what they actually need and design a solution that fits this need, you of course test it with representatives of these users and make adaptations to the site before go live.

On go-live you are confident you have a successful site in the making and sit back, update content maybe add functionality in later phases of the site as per the development roadmap and generally watch the site grow.

Trouble is the users evolve, they mature in their use of your site , their needs develop as they get comfortable they develop new ways of using the what you have delivered in ways you never considered, and, if you don’t adapt to these needs then your site will whither and die, and your visitors find a new site that fits their new behaviour better.

you need to monitor how your users try to *abuse* the functionality you have supplied and adapt the site to make it easier for them to achieve their new activity.

This is <tech-volution /> (yes i made this up)

So back to the original point, and Roberts assumption that Twitter is to say that twitter is not for conversations, this is a mistake and I’m afraid, wrong, if this where true then no-one would use twitter for conversations, the problems with using the service in this way would make it unusable, in the same way as you don’t use a fork to eat soup.

Twitter may not be ideal for conversations , it may be tricky but its not wrong, and it would not surprise me to hear that the folks at twitter are planning spend some of their $50 million to release new features for the service that allows threading for conversations, that is if tweetdeck or twhirl (insert twitter client here) don’t get there first,

That’s tech-volution.

ezvx4q29fg

Read More

Users, visitors and audience types

May 15, 2009 by jmorse in social networks | Leave a comment

In a recent discussion / interview with a member of the Eduserv research group (previously known as (Eduserv foundation) which focused on a study soon to be proposed into CSM and HEI, I was asked to define the ‘user requirements’ for content management system project.

Users.., what are ‘users’ when discussing CMS requirements, and are they the same as website users?

In a traditional sense users are often regarded as the ‘users’ of a website, UX professionals talk about user testing and user centered design processes, but when it comes to CMS the user can be seen as the ‘site; user or the CMS user, each with very different needs and thus differing impacts on your requirements exercise. It’s important therefore to make sure that you are talking about the same ‘audience’ and that you accurately address their needs.

Site users, (visitors) need to be able to find information quickly and need navigation accessible content, they may ‘use’ the functions of the site in the process of finding content but referring to them as users (in the CMS context) clutters the message. Navigation, clarity, language findability structure and design make for the site visitors experience.

The needs of the CMS user however is concerned with editing interfaces, categorization and linking, they need workflow and accessibility checkers, they need to know who did what when and how, the kind of stuff that CMS (WCMS) should do well.

Most of the time the description of the feature needed will be itself explanatory. However you should never allow ambiguity and assumption into your requirements study. (Similarly words such as ‘solution’ ‘system’ and ‘service’ should also be avoided in this context.

For example

“The solution should be accessible to users with disability”…means what exactly?

Then we get to audiences, now these are different again. An audience, in this instance, could be defined as category or group of users (or visitors) who share characteristics, interests or experience levels.

Parents, teaches and students are all audience types, as a parent I am a visitor to my boys school website. The teacher’s who create the site with their CMS is a CMS User,

Users, visitors and Audiences are therefore interlinked, but have differing views of the solution you are defining, if you are going to meet these needs you need to make sure that you and your project sponsor / customer have a shared understanding of these differences and needs to avoid the ambiguities and, even worse assumptions that add risk to your project.

Read More