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
 |