1.Hierarchy within GETSCOPE
Within GETSCOPE we work with the following hierarchy:
- Epics / Categories
- User stories
- Tasks
2.What is a User Story?
A User Story is a short description based on the wishes and needs of the (end) user and it briefly describes the needs of the (end) user. A User Story is not a functional description but makes clear what an end-user wants or needs and why it is needed.
For example:
- As a manager, I want to be able to request an overview of all current projects within my organization so that I can see what the workload is.
- As a registered user, I want to be able to request a new password so that I can still gain access if I have forgotten my password.
- As a student, I want to view my grades online, so that I know more quickly whether I have passed my exam.
User Stories are generally written by the Product Owner and then appear on the Backlog. This is the working stock of your product. These user stories are then picked up by the Team. Delivering a User Story provides a piece of “value” for the end-user. All User Stories on the Backlog together represent the total “value” that can be delivered within a project.
An example of a user story within GETSCOPE:
A short introduction in Scrum
If you want more information about Scrum and how it works, check this Youtube link;
Introduction to Scrum – 7 Minutes: Introduction to scrum in 7 minutes
3.What are Epics (or categories) within GETSCOPE and how do you use them.
User Stories come in different formats. A User Story is in most cases limited to a specific part of the product. A large User Story is called an “Epic”. An “Epic” is by definition too large to pick up and deliver in one sprint. For that, the Epic must first be cut into smaller User Stories, which are small enough to fit each in one sprint. Within GETSCOPE you can use Epics in the Agile way, but you can also use it to create categories In which you create user stories.
Below an example of the use of Epics / Categories within GETSCOPE.
<
4.What is the Backlog and how to use it.
The Backlog in GETSCOPE is intended for the user stories that must be executed during the development of the product. Generally speaking, the Product Owner makes a classification according to priority or business value, with the most important items at the top. These tasks must be taken up first.
Just before the start of a new sprint, the Product Owner ensures that a number of detailed User Stories are ready so that the team can get started with the items that have the highest priority.
GETSCOPE works with the MoSCow Method within the Backlog
What is the MoSCoW Method?
Setting priorities is always difficult. Certainly when it comes to implementing new ideas and / or technologies. Everyone within an organization always wants to implement everything directly and that is practically impossible. There are several tools for prioritizing. The MoSCoW method is one of these. It was brought up by Dai Clegg who devised the MoSCoW method within the Oracle company.
MoSCoW is a combination of initial letters that stand for something. The 2x O are inserted to make the word “moscow” legible, without meaning.
- The M stands for Must-haves,
- The S stands for Should-haves
- The C stands for Could-haves
- The W stands for Won’t haves or Would-haves.
Backlog with MoSCoW format in GETSCOPE. You can change the names of the Backlog lanes in the ‘settings’ of your project.
Before starting the MoSCoW method, it is best to start specifying the requirements package. You do this with the entire team where everyone gives input. To prevent you from making unrealistic demands, it is best to first prepare a sequence of prios. And to classify them into one of the following categories:
M – Must-haves
This concerns the minimum requirements that are set in advance and which the end result must meet. Without this requirement, the project fails and the product can no longer be used. Must-haves are essential. MUST is also explained as the acronym that stands for Minimum Usable SubseTs.
Example: Students have a final exam assignment to design and make a car that can drive at least (minimum set of requirements). The must-have in this case is that the car must be able to drive at the end of the academic year.
S – Should-haves
These are additional and highly desirable requirements, which have a high priority, but are not a requirement for a usable end product. Without these requirements being met, the product can still be used and with compliance, the product only gets added value. Depending on the time, these requirements can always be addressed later.
Example: The students may want to provide the car with a towbar (should-have), but if the car can drive without the towbar, their project is successful.
C – Could-haves
If there is time for it, these requirements can always be addressed. If not, it is not a problem and has no adverse effect on the end result. The could-haves have less priority than the should-haves. The option is only included if there is really enough time to realize it. It is also called “nice to have” and it is more a wish than a hard requirement.
Example: Students may wish to install a revolutionary music gadget in the car. Not an important (exam) requirement, but nice if they succeed.
W – Won’t-haves (en would-haves)
This concerns future wishes that are often not possible or take a lot of time to realize. If not possible, then it is wise not to put any energy into it. If realization is possible then a lot of time (and money) will have to be invested and there would be a would-have. Often would-haves are included in a follow-up process.
Example: It is not necessary for the students that the car actually goes on the road. It is a study object. If it is nevertheless a wish to drive on public roads, the car must have bodywork and meet safety requirements. Permission will also have to be requested from the Road Traffic Authority via a process.
If you want even more information about prioritizing according to the MoWCoW method, watch this video: Prioritisation using MoSCoW
5.What is a sprint and how does it work within GETSCOPE
A sprint, a defined time period, is the basis of a Scrum project. The purpose of scrumming is: “to deliver a product as quickly as possible that meets all pre-agreed criteria, without losing sight of continuous development and constant response to changes.”
Each sprint always lasts the same time, usually between 1 and 6 weeks. This is somewhat dependent on the project. A software development project of one year usually has sprints of between 2-4 weeks and a marketing campaign of a few months usually a one-week sprint.
A sprint goes through the following steps:
- Sprint Planning Meeting: In this meeting, which takes a maximum of 8 hours, the entire team discusses what needs to be done in the upcoming sprint. Together they choose tasks from the Product Backlog, which is arranged by the Product Owner on the basis of priority. After making this selection, it is determined how these tasks will be performed.
- Sprint Review: During the Sprint Review, the (sub) project is presented to all stakeholders, with room for feedback. The Scrum Team also provides insight into what they want to tackle in the subsequent sprint.
- Sprint Retrospective: After delivering a (partial) product, the past sprint is evaluated together with all members of the Scrum team. The Sprint Retrospective is scheduled as a fixed meeting after every sprint, so that points for improvement can be taken to the next sprint.
Within GETSCOPE you have the possibility to prepare a sprint in its entirety. You can prepare the sprint as a whole and prepare it before the new sprint ends. With the Backlog on the left you can put the created user stories from the Backlog on your board. Once you have created the sprint you can switch it on via the ‘Start’, ‘Stop’ button.
