281 lines
12 KiB
Plaintext
281 lines
12 KiB
Plaintext
|
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
|