Agile Management 1/3 (Agile Roles and Management of requirements in agile projects)

AGILE ROLE

agile processes perform the following roles:

roduct Owner

> roles and responsibilities: The main task is to ensure that team do what customer/end users want in most effective way. Particularly it’s task eg.
-Manage product backlog: adding / deleting / changing user stories, splitting into smaller user stories, prioritization of user stories
-Communication: with end users and product development team, explaining the operation output
> The executor: customer, business analyst representing the requirements of customer.

development team

> roles and responsibilities:
-realization of output (product / service)
-self-organizing to deliver output at the agreed conditions with the customer.
> executor: developers, testers, designers, team leader, IT Operations

teamleader

> the roles and responsibilities: The main task is to ensure that the development team had everything they need for development. More specifically, tasks such as:
-solving problems and eliminate impediments (mediator-solving conflicts among team members, solving problems with customer / product owner)
-coaching and development of individuals
> executor: team leader / project manager, or in smaller teams this role may be part-time done by team members of the development team or rotated between team members after some time(for more knowledge and skills Agile Leaders). Scrum methodology call this role ScrumMaster.

Requirements management in agile projects

specification (ie. a description of the properties and behavior) of the desired output (product / services), it is appropriate to slice into relatively small blocks, a description of these blocks and relations between them. The blocks are expressed, depending on the desired level of detail as a user story, or more detailed as tasks. Relations between the user story blocks are expressed in the form of story maps. Fulfillment of user story is defined by meeting the acceptance criteria. Acceptance criteria are the basis for the formulation of tasks and task worflow.

User Story

What: user story is a brief description of the required functionality. User story is not a specification, but a communication and collaboration tool. User Story consist of: description, order, work estimate, business value.
Who: role Product Owner manages user stories
How: user story have form: AS I WANT BECAUSE .
When: Creating user stories is realized at a specification meeting, and their modification are done continuously as needed.
Why:
Q: Why express specification in the form of blocks (user story)? A: In order to measure progress and correct deviations.
Q: Why user story should be relatively small? A: Due to more precise estimates of work. Big functionality (EPIC) are difficult to predict and therefore this estimates are inaccurate.
Q: Why use presented user story format? A:Because for understanding business problem is important to know Who answers the questions (type of user) what (goal) and why (reason).
Express “reason” help to better understand business problem, reveal problems with other user story and understand the connection between user stories (eg. the problem is solved by other user story, or problem could be solved in better way).
e.g. User Stories without justification reason:
USER STORY1: as a project manager I want to get two times per week reports of project metrics sended to my email
USER STORY2 as project manager I want to get one times weekly report on actual spend costs of project.
In these two stories user development teams do not know the reason why manager wants to have this informations in e-mail, if wants to send further these info or want it for their information .. Team don’t know story, so do story by description (or ask for the reason).

VS user story with the WHY reason:
USER STORY1: as a project manager I want to get two times per week reports of project metrics sended to my email because I want to be informed a if needed do some corrective actions.
USER STORY2 as project manager I want to get one times weekly report on actual spend costs of project to my email because If there will be significant slippage I do some corrective actions.
-> In this case, team knows reason, so they can propose other solutions such. authenticated user get access to all the relevant reports accessible through web application. This designed solution may meet both user stories in single task.

Task

What: a detailed description of the work that must be done to implement user story. (eg. User Storiy Registration may include the following Tasks: setting application server with Spring Security with support for ACL, create a DB scheme in PostgreSQL, in JS according to the MVC UI mockup creation, validation of form data to the frontend and backend ..).
How: “breaking” user story to the sequence of tasks
When:sprint planning meeting
Who: Members of the development team
Why: detailed technical description required for completing the user story, in order to allocate right human resources.

User Stories Maps

What: connection of user stories(into stories/use cases)
How: the creation of the most common sequences of users
Why: to understand the required functionality in the context of, contributing to the creation of what the customer really needs.
Product Backlog

What: group of prioritized and estimated user stories
Who: responsible for managing the Product Backlog is the product owner
Why: to determine what (the functionalities) when (delivery time) in what order (with priority for the most valuable and also the least labor-intensive functionality) should be done
How:
– Initial formation of user stories is realized at the specification meeting
– Prioritization of user stories is realized at release meeting with whole team.
Prioritisation = business value / costs
costs= estimate of labor input (in ideal points or more hours in the estimation) and risks
business value= importance expressed in points. possible use of value stream mapping (used widely lean tool designed to value added process steps), Moscow, Kano model
Prioritisation is customised by the business perspective and also technical perspective(connection between technical bags).

acceptance criteria

What: Detailed functionality description of user story in example (specification by example)
Who: Product Owner
Why: to determine when a user story as finished and also for
better understanding of the business problem and thus make its what customer really wants.
When: Creation of acceptance criteria is realized at the specification meeting, and their customisation is carried out continuously as needed.

TIP: acceptance tests should be transformed into the form of automated E2E BDD tests (more testing in XP). BDD is a test can be done based on desired level of quality and quantity of resources on the several levels: simulation of user actions (eg. selenimum), testing frontend functionality (eg. for JavaScript Jasmine) or BDD testing backend (spock, cucumber).

marek malý

marek.maly@ambiso.sk

Like helping people, Business & IT, research & innovations, nature, travelling, sports(bike, mountaineering, ..)

No Comments

Post a Comment