openscrum/TODO

281 lines
12 KiB
Plaintext
Raw Normal View History

2012-04-13 19:18:01 +00:00
What is OpenScrum?
OpenScrum is a tool for agile development. It is a web based tool to manage
your project development. The stakeholder adds a project, gathers a team, they
both add their ideas to the project, and they are ready to go!
Add your ideas, approve the ones uploaded by the team, and they can start
developing them.
What OpenScrum is not?
OpenScrum is not an issue tracker. Although the product backlog can be seen as
one, issues should be tracked in a separate software. The OpenScrum team uses
Bugzilla for this purpose.
OpenScrum is not a project planner. Although the product and sprint backlogs
can be seen as one, it doesn't (and won't) provide all features of a project
planner.
How does it work?
First of all, a stakeholder and a developer must register on the site. Then,
the stakeholder must create a new project, and within the project, a team.
Then, the team must be filled with members. For this, the stakeholder may put
on some advertisement, so developers can contact him for details. Then the
stakeholder invites the chosen developers to his project's team.
Then the idea pool is filled (of course, this can be started while inviting the
developers). When added, both parties need to add a positive vote on it to put
it in the product backlog.
If the project is an already working one, it may have a bug tracker from which
you can import bugs as user stories. Be warned however, that bugs added this
way will only be fixed at the end of the sprint, so a better approach to this
would be to fix critical bugs between two sprints, or to dedicate a developer
who will not work in the next sprint, but fix bugs instead.
The product backlog is priorized by the stake holder, and their development
time is estimated by the team. If the estimated time is larger than the sprint
length, the poster of the story is notified to break it down into smaller
stories. If he doesn't do it, the story remains in the backlog with the long
estimated time. Otherwise, the story is removed from the backlog, and the
poster can break it down into smaller parts.
According to the sprint length, the user story estimations and priorities, the
team and the stakeholder create the backlog of the next sprint. The team will
use this backlog during the sprint.
During the sprint, the team and the stakeholder should reduce communication to
a minimum level. However, sometimes it is required to discuss something. This
can be done within the specific user story using a chat function. The sprint
backlog can not be changed during a sprint, as it would change the sprint's
length. Instead, in the discussion, the development of the story can be halted.
This, of course will mean that tha story will not be finished at the end of the
sprint and will appear as unfinished in the review.
OpenScrum also provides some help during the Daily Scrum. It provides a chat
interface on which Team members can discuss the last and next day. If the Team
holds the Daily Scrum in person instead, the Scrum Master should upload a brief
extract of the Daily Scrum for documenting purposes. These documents are unseen
by the Product Owner unless otherwise stated by the Scrum Master.
During the development Team members can login anytime to see or update the
status of user stories. Some parts of these updates are published to the
Product Owner, so they can monitor the development's status.
When the Sprint is finished, OpenScrum may come in handy for the Sprint Review,
either.
Do I have to use this page?
The projects you upload on OpenScrum.org can be seen by you and the development
team you assig to it. However, if you want to hide it even from our selected
few database administrators, you can buy the OpenScrum.org code to run it on
your intranet server.
If you buy it, you get a one year read access to our Git repository, so you
will get all the patches and new features during that period.
Terms
=====
Product
-------
Idea
----
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
DATABASE PLANNING
======================
User:
id: integer, unique
username: string, unique
password: string, hashed or crypted
role: enum of pig and chicken
scrumMaster: boolean, only one scrum master can exist
Team:
id: integer, unique
name: string, unique
members: array of user ids, only pigs can be team members, one pig can be
the part of multiple teams
Product:
id: integer, unique
name: string, unique
contact: text, may be omitted
productOwner: integer, unique, id of a user, must not be the scrum master
teams: array of team ids working on this product
productBacklog:
id: integer, unique
productId: integer
storyName: string, unique
storyDescription: text
difficulty: integer, must be null during the difficulty vote, counts as an
accepted story otherwise
businessValue: integer
ideaPool:
id: integer, unique
productId: integer
storyName: string, unique
storyDescription: text
difficulty: integer, optional
difficultyVotes:
storyId: integer
userId: integer
difficulty: integer
reason: text, optional
Sprint:
id: integer, unique
productId: integer
started: timestamp
title: string, must be unique among the same product's sprints
sprintBacklog:
id: integer, unique
storyId: integer
teamId: integer
title: string
briefDescription: text
longDescription: text
hourRequirement: integer
OpenScrum.org user stories
==========================
• as the site owner, I want unregistered users to access the information pages
and public Products only
• as the site owner, I can decide if I want to allow anyone to register
• as a possible later Product Owner, I can register my company providing a
contact e-mail address, and optionally uploading a brief description of it
• as a possible Product Owner or Team member I can register myself by choosing
a username and password, providing a contact e-mail address, and optionally
uploding my CV with references and some details about myself
• as a registered user, I am able to log in to the site using my chosen
username and password
• as a Product Owner I can create a new Product on behalf of my company
• as a Product Owner I can create advertisement about my product to find
developers for my Team
• as a Product Owner I can invite developers to my Team
• as a Product Owner I can choose a possible Scrum Master from my Team
• as a Team member I can vote with a plus or minus on the chosen Scrum Master
• as a Product Owner I can set who can add items to my Product's Idea Pool: me,
the Team, or anyone
• as a Product Owner, Team member or a normal registered user I can add items
to the Product's Idea Pool depending on the Product's settings
• as a Product Owner or Team member I can vote with a plus or a minus on the
Idea Pool items depending on the Product's settings
• as a Team member I can estimate the difficulty or required time for each item
in the Idea Pool
• as a Product Owner, I can see the difficulty or development time estimated by
the Team
• as a Product Owner, I can promote one of the Team members to Scrum Master
• as a Team member, I can put a positive or negative vote on the promoted Scrum
Master. If enough positive votes are gathered, the promoted member will
become the Scrum Master. If enough negtive votes are gathered, the selected
person will automatically be demoted, and the Product Owner has to promote
again
• as a Product Owner or a Team member (or optionally, as a regular user, if the
Product is public), I can add my ideas to a Product's Idea Pool
• as a chicken, I can see if my product has an active sprint
• as a product owner, I can enable or disable chicken access to sprint details
• as a team member, I can see the backlog of each products, and can vote for
the difficulty of each story
• as a product owner or customer, I can see the idea pool, and can accept or
decline the ideas in them. If I accept them, they automatically get into
the product backlog
• as a product owner or customer, I can define a business value for each item
in the product backlog, thus accepting them from my side
• as a team member, I can vote for the difficulty of each user story in the
product backlog or the idea pool with an optional reason, thus accepting
them from my side
• as a product owner, I can import tickets from ticketing systems. Bugs get
into the product backlog, feature requests go to the idea pool
• as a product owner, I can start a new sprint for my product
• as a team member, I can help the product owner in creating a new speint, by
dividing the user stories into tasks, predicting an hour requirements for
each one
• as a product owner or customer, I can edit user stories with high difficulty,
so it breaks into smaller tasks, or I clear some things
• as a team, we can agree on how we will solve a task, and we can add and
modify these details to an open task anytime
• as the scrum master, product owner, and optionally as the customer, I can see
statistics and charts about my ongoing sprint