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