72 lines
2.5 KiB
Plaintext
72 lines
2.5 KiB
Plaintext
How does it work?
|
|
|
|
User story sources:
|
|
|
|
Idea pool
|
|
• virtually anyone can add stuff
|
|
• team may define difficulty level
|
|
• customer must create a user story from it or decline it
|
|
|
|
Customer requirements
|
|
• customer can add stuff
|
|
• team must define difficulty level
|
|
|
|
Optional bug tracking system import
|
|
• import bugs and feature requests from different tracking systems, these items
|
|
become special user stories
|
|
• these entries always get into the product backlog, without customer approval,
|
|
as high business value items
|
|
|
|
Product backlogs:
|
|
|
|
• customer can priorize user stories by business value
|
|
• customer must refine the user story, with the aid of the team if necessary
|
|
• teams can vote for actual story difficulty. Only those stories make into the
|
|
product backlog, which is approved by both the customer and the team:
|
|
customer simply approves (yes/no), team assigns difficulty as approval
|
|
(with a successful vote)
|
|
|
|
Sprint backlogs:
|
|
|
|
• product owner must define the title of each sprint
|
|
• the team must break down the user stories into tasks
|
|
• the team must set time requirement for the tasks
|
|
• the tasks must have a title, a brief and long description and a time frame
|
|
• chicken access to sprint backlog and task status may be disabled
|
|
|
|
Help for the daily scrum:
|
|
• display the task states
|
|
• display the product burndown charts
|
|
• the team can do the daily scrum via XMPP-based chat, integrated into the site
|
|
• tasks can be moved at any given time, all charts and reports are updated real
|
|
time
|
|
|
|
Sprint review:
|
|
• at the end of a sprint, the customer can accept or decline user stories,
|
|
depending on their readiness
|
|
• after closing the stories, the sprint itself is closed automatically
|
|
|
|
Sprint retrospective board:
|
|
• this is only a small blackboard, on which team members can discuss everything
|
|
about the current sprint. This is only a tool to aid the scrum master
|
|
during the retrospective.
|
|
|
|
Users and roles:
|
|
• each user can be a chicken or a pig
|
|
• any pig can be assigned to the special role "scrum master"
|
|
• the scrum master cannot be a product owner for any products
|
|
|
|
Products:
|
|
• each product must have exactly one product owner
|
|
• all products must have a product description and may have customer
|
|
information
|
|
|
|
Teams:
|
|
• all team must have at least one member to be considered as active
|
|
• product owners and the scrum master can be the member of any team
|
|
|
|
Sprints:
|
|
• every sprint mst have a goal
|
|
• at most one sprint must exist for each product at any given time
|
|
|