Insights

There are a number of different roles in the agile methodology, and these need to be well-understood to make agile work effectively in your organisation. In particular, the scrum master and product owner need to have enough time to devote to doing their roles properly. I must mention that as a female developer, I find a lot of the terminology used in Scrum rather macho and off-putting. I would like to see a shift in the culture on this, but unfortunately, the terms seem to be pretty ubiquitous these days. A Scrum team. Photo by  Nghungdo –   CC-BY-SA 4.0 . Developer The agile developer is a team player who commits to standardised development practices and sharing knowledge across the team. They are comfortable in different layers of the stack,m though they generally specialise in one of the layers. In agile methodologies, the development team gets to decide which of the top priority stories in the product backlog they will work with next. Scrum master The scrum master manag...

Different project management tools will work for different types of work and different scales of organisation. Depending on the context, your project may work better with agile, lean, scrum, kanban, or some hybrid approach. Use the right methodology for the project Agile methodologies like Scrum work really well for development projects, usually ones where the team is focusing on one project at a time.   Agile approaches to marketing have also been devised, as the funnel approach to marketing lends itself particularly well to an agile process. According to the Scrum Alliance , Scrum is an Agile framework for completing complex projects. Scrum originally was formalized for software development projects, but it works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple. For tasks that are a one-off instance, such as support requests, a system like kanban , which enables staff to prioritise incoming tasks, may work...

Agile development is an iterative and flexible process. Rather than specifying all the requirements of a project up-front and adhering to them throughout the development process (as happens in waterfall development), the requirements are listed as items in a product backlog. Specifiying software in this flexible and responsive way is better for customers and better for users. The product backlog is prioritised by the ' product owner ' (a role that represents the business users of the product to be developed). They can change the priority of an item in the backlog at any time. Each item in the product backlog represents a block of work to be done, which should ultimately result in ' shippable product ', otherwise known as a feature that users can use. Items in the product backlog are called 'user stories', which can be an epic (an overarching dewcription of some functionality), a spike (a time-boxed investigation), a bug (broken functionality that needs fixing), ...

A persona describes one category of the target users of your system as a fictitious but realistic person with goals and needs. It is useful because it summarises the user, their role, their skills and aptitudes, their preferences, and their goals. Personas give rise to user stories, and keep the user stories focused on the goals of real users. The persona needs to include a name and a picture, so that developers, business analysts, and testers can relate to it as if it was a real person.  It should include the following details: their demographic characteristics (e.g. age, disability) that might affect their interaction with the product, and their requirements in using it their role in using the software (e.g.  admin, editor, contributor, supervisor) what their job title is activities they do in their spare time which might affect their performance (either beneficially or adversely) their goals in using the software common tasks they will want to carry out using the software W...

User stories are part of the Agile process. Agile development is iterative and broken down into sprints. Each sprint delivers “shippable product” – something that can actually be used by users, and which has business value. A user story looks like this: “as a [role], I want to do [task], so that I can achieve [goal]”. A non-technical reader who knows nothing about the system should be able to read your user story and understand it.The user story should not describe the technical details of how the goal will be realised; this should be left to the developers. The aim of a user story is to describe how the system will deliver business value to the end users. There are different types of user stories for different situations. You should write "epics" at an early stage, when you are working out the concepts behind the system, and the overarching problems you want to solve. Later, break your epics down down into more manageable user stories (features) at the point when you are nea...