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...
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...
Comments
Post a Comment