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...

For agile methodologies to succeed, there needs to be maximum transparency and planning. A number of agile artefacts have been developed to ensure that the team and the stakeholders have a clear understanding of what's happening. Burndown chart For each sprint, the development team commits to developing the features described in a number of user stories . Each story is assigned a number of points during the estimation meeting . In order to ensure that all the promised features are developed during the sprint, the scrum master keeps a burndown chart to measure the team's velocity. On day one, the total number of story points is marked on the top left of the chart. The next data point represents the remaining story points after the stories completed on day one have been subtracted. The ideal trajectory is a straight line. If the team slows down (indicated by the "actual tasks remaining" line being above the "ideal tasks remaining" line) then they need to spee...

Agile methodologies like Scrum sound amazingly efficient when presented by people who have implemented them in a non-hostile environment. But conditions are not always perfect, and things can sometimes go wrong. One of the key features of agile project methodologies is that they have different types of meetings . Each different type of meeting has a very specific function. They can become tedious and unproductive if they deviate from the prescribed form and function. With that in mind, let's look at the different types of meeting, how they are meant to work, and what can go wrong. Three Amigos     © Copyright  Peter Trimming  and licensed for  reuse  under this  Creative Commons Licence . Three Amigos This is a relatively new type of meeting in the agile toolkit, and was developed in 2013 . Essentially, this is a meeting during which the business analyst (BA) presents the requirements and tests for a new feature. The Three Amigos (BA, developer, and QA...

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...

Behaviour-driven development (BDD) has emerged from the practice of test-driven development (TDD). Whereas TDD focused on making sure that code worked and caught exceptions gracefully, BDD focuses on making sure that the functionality delivers business value and satisfaction to users. A typical BDD process might look like this: In behaviour-driven development: User behaviour drives development The team elicits user stories An analyst creates feature files The feature file becomes the test harness for development The team develops and tests against feature files The key features of BDD are: we write behaviour & specification that then drives our software development.  features are based on actual user behaviour & scenarios & user stories. the tests can be written by business analysts and stakeholders. The advantages of this approach are: Developers deliver what the users actually want It is rigorously tested The test shows that the feature meets the requirements (as oppo...

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...