recursal/Fanatic-Fandom huggingface dataset:
Gumball Watterson

**Gumball Tristopher Watterson** ist der Protagonist von Die fantastische Welt von Gumball. Er ist eine zwölfjährige, blaue männliche Katze, die mit seinem Adoptivbruder Darwin und seiner vierjährigen Schwester Anais in die Elmore Junior High geht.

## Auftreten

### Altes Konzept

Ursprünglich war Gumball ein blauer Hund. Ohne viel zu denken wurde es in diese Wahl gesetzt, da es eher ein Platzhalter war als ein endgültiges Design. Als die Schöpfer den Charakter weiter entwickelten, beschlossen sie, ihn zu einer schwarzen Katze zu machen, um die Persönlichkeit zu treffen, die sie für ihn im Sinn hatten: Unglücklich, aber optimistisch (schwarze Katzen symbolisieren Pech). Die Schöpfer fanden dieses Merkmal zu beschränkend in Bezug auf mögliche Geschichten. Die Entscheidung wurde festgelegt, das Gumball blau sein soll, weil Blau nicht eine Farbe ist, die gewöhnlich auf Katzen gefunden wird.

### Endgültiges Design

In der eigentlichen Show ist Gumball eine hellblaue Katze. Auf seinem überdimensionierten Kopf hat er sechs Schnurrhaare, aber nur fünf sind die meiste Zeit sichtbar, weil sein Kopf meist schräg dargestellt wird. Er trägt gewöhnlich graue Hosen und einen braunen Pullover, der braune Bündchen und einen braunen Kragen hat. Wie seine Mutter und sein Vater, trägt Gumball keine Schuhe und ist das einzige Mitglied der Wattersons ohne sichtbare Wimpern, obwohl er in einigen Episoden mit sichtbaren Wimpern gesehen wird. Das Innere seines Mundes ist rosa, seine Zunge ist hellrosa, und seine Nase ist orange. In der 2. Staffel ändert sich sein Design leicht. Sein Kopf und seine Schnurrbärte sind größer, während seine Augen und der Zahn runder sind. In der 3. Staffel sind Gumballs Augen mit dem Rest der Wattersons alle komplett rund.

## Persönlichkeit

Gumball ist ein ziemlich sozialer Typ, und hinter den meisten seiner idiotischen Einfälle verbirgt sich der Wunsch, anderen etwas Gutes zu tun (auch wenn das in den meisten Fällen völlig daneben geht). Wenn er manchmal wütend über irgendetwas oder irgendjemanden wird, ist das meist eher gespielt und immer nur von kurzer Dauer. Er ist heimlich in Penny verliebt, die keimende Erdnuss. Trotz seiner Wildheit versucht er aber im Allgemeinen ehrlich, höflich und warmherzig zu sein. Er respektiert seine Mutter, aber macht sich oft über seinen Vater lustig.

## Trivia

* In Episode "Der Betrug" mag Gumball keine Rosinen, weil sein Originalsprecher Jacob Hopkins auch keine mag.
Typical Agile Metrics

In agile it is important to stay up
to date with any tracking and reporting of a project.  There needs to be an emphasis on knowing what
the business needs and so you can relay the information back to the team.  Tracking both the business needs and the agile
metrics will be key in the development process.

## Sprint Burndown

The scrum meetings should
incorporate a burndown report showing the completion of tasks throughout the
process.  The X axis will represent time
and the Y will represent the work that is incomplete measured in either points
or work hours.

(Image from Atlassian)

In this chart we see that the forecast for the work is about the same
throughout the sprints.  It also accounts
for the days that the team is not working.
The drop in the remaining value indicates that tasks have been
finalized.  Things to watch for include
not committing enough work, committing too much work, steep drops due to
course-grained pieces, and the product owner’s additions and changes in the
scope mid sprint.

## Release Burndown

Release burndowns are also known as
version or epic charts.  They track the
progress of a larger body of work.  They
help in guiding the team through the differences in several epics and
versions.  Scope creep is a usual
consequence in the agile process so it is best to track any changes the scope
has gone through whether it be new features or just something that the product
owner wants to remove or incorporate.

(Image from Atlassian)

In this chart we see the big
picture of the burndown with the forecast, completed, remaining, and any work
that has been added to the sprints.  Things
to look out for are: scope creep, the progress completed,  and any incremental changes.

## Velocity

Velocity is the amount of work completed in a sprint over the amount of work left or in other word it’s the average of the amount of work either in value points or work hours.  It is important to note the change in velocity throughout the project.  The
software requirements may not be optimized by the team and so visually seeing
it through a chart will help in guiding the team through the planning and
retrospective.

(Image from Atlassian)
Things to look out for is any unplanned roadblocks, if the business is
affecting sprints, and if the team is too zealous in forecasting the sprints.

Citations

Atlassian Five Agile Metrics You Won't
Hate The Agile Coach. In: Atlassian.   https://www.atlassian.com/agile/metrics.
Accessed 27 Nov 2017

In: Burndown Charts.
http://www.agilenutshell.com/burndown. Accessed 27 Nov 2017
Idle Poring Wiki

## Welcome to the Idle Poring Wiki

If you're looking for some help or just want to learn a bit about the game this is the place to be!
You can also add your own information to help out others!

Daily Quest | TODO | Jobs

> "We, the active editors of this wiki, decided that only registered FANDOM users may edit this wiki.
>
>

> This step was needed in order to reduce vandalism on our articles. Thanks for keeping with us!"
>
>

## Describe your topic

Write a description about your topic. Let your readers know what your topic is about and add some general information about it.

## Latest activity

Photos and videos are a great way to add visuals to your wiki. Find videos about your topic by exploring Fandom's Video Library.

File:Placeholder
Der Anfang

**Der Anfang (1) + (2)** ist eine Episode der ersten Staffel aus Die fantastische Welt von Gumball.

## Inhalt

Mom und Dad wollen das hyperaktive Kleinkind Gumball unbedingt davon abhalten, das Haus auseinanderzunehmen, und beschließen, ihm ein Haustier zu schenken. Der Plan funktioniert, doch ein Problem bleibt: Kein Goldfisch, den sie kaufen, lebt sonderlich lang. Als Dad eines Tages in einem seltsamen Laden einen sprechenden Goldfisch findet, ist das der Beginn einer wunderbaren Freundschaft. Als Darwin versehentlich die Toilette heruntergespült wird, gelangt er durch die Abflussrohre irgendwie ins offene Meer. Panisch vor Angst, doch fest entschlossen, zu den Wattersons zurückzufinden, macht er sich auf den Weg zu seinem Zuhause bei Gumball. Das ist jedoch gar nicht so einfach, schließlich kommt ein Fisch auf dem trockenen Land nicht sonderlich weit.
Grouping with themes or epics

In your Agile group you have your user stories, but it seems like some user stories belong in the same category with each other and others don’t seem to correlate. When this happens you need to make something called an Epic or a Theme.

An Epic or a Theme is “a way to organize similar stories into appropriate workstreams” (Rose). And Epics/Themes are typically created after the team creates the user stories. There are many ways to organize similar user stories, one is “grouping together a similar value proposition”, meaning higher valued stories with other higher valued stories, this can keep the group focused on the more important stories. There are many other ways to group stories, it’ all depends on the group and the situation.

In the lynda video, Doug Rose says that the product owner usually creates a large value statement instead of several smaller stories, which is okay because that’s how most people think. In that situation we need to work backwards and break the Epic into smaller parts that all combine together to make the original Epic. These Epics are typically large anyways and are not the same as user stories, when the product owner gives a huge task that seems vague that’s an indicator that the team should break it down into user stories.

There’s an 8 step process that can be remembered by the acronym “FEEDBACK”. In this article, I’m only going to give a brief description of what FEEDBACK is, if you want to learn more about it watch this (Lynda).

F stands for Flow, this is how the story might go through the application’s workflow. E stands for Effort here you might break down the epic based on the developer’s level of effort. E stands for Entry, sometimes the team might want to break down the epic by how the customer enters the data. D stands for Data operations, you may want to break up your epic based on common data operations, such as read, update and delete. B stands for Business rules, sometimes you’ll see there’s a lot of complex value in the epic, when this happens you may want to to split that epic down into business rules. A  stands for Alternatives, some epics can easily be broken into stories with alternative criteria. C stands for Complexity, product owners start thinking, they find greater and greater value, when this happens the epic is just a simple start, then you can break it down into stories with increasing complexity. And finally K stands for Knowledge, sometimes the product owner will present the epic and the team will need more knowledge, when this happens the developers will create spikes.

“They are naturally grouped together and need to be split up.It's like an orange that falls to you, naturally whole. Now you have to go through the process of splitting it into edible segments.”
Role of Scrum master in meetings

The Scrum Master is a working leader or coach for an agile approach to
software.  They help inform the team and guide them to ensure the process is being followed.  They also aid in clearing up any roadblocks
that the team might come across.  They
help the team deliver with continuous feedback and incessant improvement.  Scrum masters facilitate coaching practices to implement good software principles and eliminating and impediments to encourage steady work flow.

Responsibilities

·
**Facilitating**
meetings **– Throughout the entire process, through all the stages; the Scrum**
Master is able to inquire with the team to discuss the work through the daily
standup, the interation planning, review, and retrospective.

·
**Supporting**
the Product Owner**-  As Scrum Master**
it is necessary to be able to work together with the owner and discuss any
changes managed through the backlog and to guide the scrum team to abide with
the priorities as well as the scope of the operation.

·
**Promoting**
healthy practices **– At the end of the day the deliverables should be tested**
for reliability and quality.  The Scrum Master’s
job is to encourage good practices with technical depth and efficiency.

·
**Eliminates**
any Impedances **– The Scrum Master will have the responsibility to free up**
any roadblocks that the team is facing and address issues relating to the
objectives of the requirements. Some issues will need to be helped from other
scrum teams.

·
**Building**
a productive team **-  During meetings**
the Scrum Master will make it a priority to work together fluidly and to
promote a focus on dealing with any challenges, conflicts, and growth
opportunities.  Management skills are
necessary to resolve the issues and help the team with personal problems.

·
**Communicating**
and negotiating **– The Scrum Master must be adept to handle the demands of**
management as well as protect the team from any unnecessary expansion of work.

·
**Coordination**
with others **– The Scrum Master will be the person to represent the team at**
times to incorporate with the system team, software architecture, and the
services that are shared with the project.

·
**Supporting**
the estimates **– The scrum master will have a hand in on the estimation**
process to help the team to ensure the right principles are in place for
normalizing estimates.

http://www.scaledagileframework.com/scrum-master/

Leffingwell,
Dean. Agile Software Requirements: Lean Requirements Practices for Teams,
Programs, and the Enterprise. Addison-Wesley, 2011.
Quimica Mexico Wiki

Actualmente hay 13 artículos en Quimica Mexico Wiki

Hoy es martes 30 de enero y son las 01:00 horas.

## Descripcion

Esta wiki que actualmente cuenta con 13 articulos y va a tener mas.

El propósito de esta wiki es enseñar a las personas mexicanas sobre química en un estilo de wiki de videojuego.

## Novedades

04/10/17 - Se termino la tabla periodica.

04/10/17 - Se añadieron varias paginas.

## Colabora con este wiki

Para escribir un artículo, ingresa el título en la caja de abajo.

<createbox>
width=24
break=no
buttonlabel=Crear un nuevo artículo
</createbox>

* Piensa bien antes de añadir un articulo, revisalo y si infringe alguna norma,corrigelo.
Technical User Stories

User stories are a very important part of agile development,
but there is another type of user story that is just as important and is used
to supplement user stories. That is the Technical User Story. A Technical User
Story is focused on the non-functional support of a system. Examples of this
may include security or performance, or scalability and architectural work. All
of these and more fall outside the realm of the user stories and there for need
the technical stories when developing them.

A major difference between user stories and technical stories
is that a user story is focused around functional descriptions of the behavior
of a system.  Technical User Stories
however are used to support the upper level behavior of the system and so are
often also call infrastructural stories. The Technical user stories help to
prevent overloading of a user story by taking the load of the basic infrastructure
off the user stories.  Otherwise user
stories would be much longer.

Technical User Stories can be easily forgotten when there is
a backlog of maintenance activities. It is easier to focus of functionality and
to ignore the technical infrastructure or push it back until much later. A way
to bring user stories to the forefront is to perform a story brainstorming
workshop as well as an end to end release plan. The end to end release plan
helps you to see the who project and this way can bring out the technical stories.
Another way to figure out what you would need for your technical stories is to
look at the acceptance criteria.

There are five basic technical stories that you should be
able to identify: Product Infrastructure, Team Infrastructure, Refactoring, Bug
Fixing, and Spikes. Product infrastructure are stories that directly support
the functional stories. They could be infrastructure that has to be newly
created or molded around the function. Team Infrastructure are stories that
help to support the team and helps them to deliver the software. Refactoring
are simply stories that focus around areas that a refactoring candidate, whether
they are code, design, automation tools, or process documentation. Bug fixing
are clusters of bugs that would increase repair time or decrease testing time.
These stories are more for efficiency. And finally spikes are stories that are
more prototype code over actual documentation, and are created when the storied
or design calls for them to make the functional requirements be met.

While it is not necessary to have to separate the user
stories and technical stories into separate groups, it is important that you
and your team know that there is more to writing user stories then just focusing
on the functional aspects of the project, and that they are prepared to meet
these challenges when they are faced with them.
Making good team decisions

A big part of doing retrospectives is not only for you as an individual but you as a team to improve on the next and every other project. That is a given, since this is a team effort. Now, every retrospective should have list of “action” items to work on for next sprint/project. An action list is basically a list that your team and you come up with to improve on that lacked or failed in the prior sprint.

So, what does making good team decisions have to do with action items? Well, as a team you should come to a consensus of what to place on the action list. Sounds easy at first but when practiced there can be a lot of mistakes that happen and teams become narrow-minded by focusing on small fixes that can take up time and energy and still places the team in a stagnant maybe even regression state. An example problem/challenge that could happen, this is directly from Doug Rose on Lynda, is “The first challenge is too much talk and not enough action. Sometimes this is called a kvetchrospective”. Kvetchrospective is derived from the yiddish word Kevetch, which means “The first challenge is too much talk and not enough action. Sometimes this is called a kvetchrospective” That’s why making good team decisions are really necessary, important and relevant.

This was only one of three challenge that most teams will face when trying to make a good team decision on what to add and work on the action items. Just remember the challenges that can happen and work hard with your team to avoid them and benefit from fixing the action items.

1. ↑ https://www.lynda.com/Business-Skills-tutorials/Create-clear-action-items/175961/468254-4.html
2. ↑ https://www.lynda.com/Business-Skills-tutorials/Create-clear-action-items/175961/468254-4.html
Showing daily progress

Showing daily progress is a key concept in Agile. To keep the whole team on track and to keep everyone on track there are charts and task boards. I’m going to talk about creating the task board, reading the task board, updating the task board and sizing the task board.

Creating the task board, to start creating I think the best way is to first know what a task board is. “Often managers will use the task board as a signal of progress”, that being said this a board that shows the progress of the project to the team. Now, how does someone create the task board? “It’s usually displayed on a large white board with marker columns. Sometimes it will be simple tape on a white wall”(Rose) Typically, a team will make use of whatever they have around them to make their board with their tasks.

Reading the task board, “A quick glance at the board should tell you everything that you need. It should be simple and clear”(Rose) Reading the task board isn’t just for the task but also can be read into, to find out the morale of your team. If you’re the scrum master than you should visit the board frequently to see if it’s well populated or not. If it is then it shows your team is committed and passionate, if not then you need to find out if the team is working well together.

Updating the task board, the first thing to know is that the developers should be the only one updating the task board. If the project manager start to move things around it can mess up the flow going on now. Normally, the task board will be updated during the stand ups and each task should be the work for one developer.

Sizing the task board, “in Agile, it's very important to size the work in each sprint. It's a key part of how the team plans out the project.”(Rose). Basically, this board is a representation of how many tasks are left, it’s also there to keep the developers on task. If the task isn’t on the board, the developer should not be doing it.

This is just a picture of a task board from Google images!
Estimating time of project with user stories

“In 1914 Henry Ford noticed that his employees worked best when limited to eight hours. After eight hours, their productivity began to slow down.That's why Ford Motor established the 40 hour work week. The change increased their productivity and many companies soon followed. That's why the 40 hour work week became standard.”(Rose 00.00-00.20) Thanks to Henry Ford we now have 40 hour work weeks,that being said we also adopted this into Agile due to the higher productivity that was shown in this.

When starting agile, the scrum master needs to be able to estimate how much time each task should take. A perfect agile project, is said to “run like a marathon”(Rose 01:20-01:22), meaning “a rigorous but consistent work pace”.(Rose 01:20-01:25)   But how can the scrum master or the team members estimate how much time it will take them to finish an individual task? This is where calculating velocity comes in.

Velocity is defined in the video as “How much work teams have done and how much they’ll do in the future.”(Rose 01:42-01:52) A better way to explain it is basically, a team will look over it’s past sprint to see how long it took to finish each task and will apply it to the next sprint.

So, now you understand what velocity is but how would a scrum master and their team use it practically to estimate how much time a project will need? Well, a scrum master and their team places story points, on each user story, the scrum master would place a higher point value on the more time consuming/more complex stories and lower point values on less time consuming/less complex stories and after a couple of sprints average these points out to get the velocity. It can become frustrating at first to estimate an accurate time but if a group continues to practice it, with time, can become more accurate and be a huge benefit for the team. With this a team can estimate how long it will take them to complete a project and if a team wants to be more active they can even figure out how long it should take each sprint.

1. ↑ www.lynda.com/Business-Skills-tutorials/Calculating-your-velocity/175074/387220-4.html.
2. ↑ www.lynda.com/Business-Skills-tutorials/Calculating-your-velocity/175074/387220-4.html.
3. ↑ www.lynda.com/Business-Skills-tutorials/Calculating-your-velocity/175074/387220-4.html.
4. ↑ http://www.agilechamps.com/wp-content/uploads/2017/02/Story-Points-vs-Times-300x174.jpg
Gathering requirements with product owner

In a agile methodology gathering requirements with the product owner remains one of the most important things to discuss. The product owner is a key stakeholder in all matters relating to the product. The project can be determined by the owner and they can make changes how they see fit. Gathering requirements remains a key component in deciding how to achieve the goals listed in the project.

Goals can include anything that the product owner see fit for the project.
It is important that all members know what the owner wants and the requirements
of the project.  In determining the
requirements the team must know what type of technologies are required along
with the feasibility of the project.
This means not having requirements that are not yet possible.  It is imperative to have a discourse on the
data of the project.Gathering requirements involves knowing what the
owner wants in the project.  This can be
a plethora of things but it is the teams decision to decide if it is capable of
doing the work.  They decide what they
want and when they want it.  The first
thing to consider in teams is to decide how to meet the requirements and make
the product owner happy.

1. ↑ https://re-magazine.ireb.org/issues/2014-2-gathering-speed/product-owner-in-scrum/
2. ↑ https://re-magazine.ireb.org/issues/2014-2-gathering-speed/product-owner-in-scrum/
Generating good insight

At the end of a project teams go through something called a retrospective. A quick Google search of what does Retrospective mean in terms of project management, I found a definition. Inloox defines retrospective as, “A retrospective is an agile method, most often associated with the scrum methodology (‘sprint retrospective’). It describes the regular meeting of the project team. During such a meeting, the team looks back at their achievements and reflects on how to improve future projects.”

Now that you have an understanding of what a retrospective, we can get into how to get the ball rolling. At the start of the retrospective you and your team reflects and tries to generate good insight about the achievements failures and how to improve on future projects. In a perfect world, when doing a retrospective in your team, you want everyone to participate so you improve as a unit, but this isn’t a perfect world and everyone is different.

This poses a problem, what happens when your group has some people with strong personalities, extroverts and the other people on the team are introverts and aren’t as strong being open with their ideas? You get those strong personality people taking over the retrospective. Doug Rose from lynda says “One thing you might find with retrospectives is that a few strong personalities will do most of the talking.”, which doesn’t get the whole team involved and that could potentially stunt the growth of the next project.

How to get everyone involved now? Doug from Lynda’s idea was a game, which he says some companies don’t do because it doesn’t seem “professional”, but it can be really helpful. The game is the called the “Question Circle”, which basically everyone has to get involved and give their input. This is a great way to generate good insight from EVERYONE on the team and can help improve the next project especially if the whole team is involved.

* Get everyone involved!! Make an environment comfortable enough so everyone can present and give everyone in the team a chance to get what they want to say out.

1. ↑ www.inloox.com/project-management-glossary/retrospective/.
2. ↑ https://www.lynda.com/Business-Skills-tutorials/Use-games-simulate-reflection/175961/468250-4.html
Productive Meetings: Staying Lightweight

Lightweight Scrum Activities

Throughout the life cycle of an agile project, teams will
actively participate meetings called daily scrum. These impromptu meetings are
meant to help developers hammer out details and sort out any problems that have
occurred. In agile, it is important to keep these meetings lightweight. This
means that they are well structured and scheduled. The underlying purpose for
this concept is to ensure that these meetings are productive.

The structure of a meeting can quickly determine whether
it is successful or not. When structuring the meeting, all team members are
required to attend. This includes both the Scrum Master and product owner.
Leaving out key figures will spell out disaster for the project. The daily
scrum meeting should focus on what each team member accomplished yesterday and
will accomplish today. By doing this, the team will gain understanding of the
work completed and the work that still remains. The daily scrum is not a status
update but a meeting for team members to make commitments. These commitments
are the contributions to the project. Committed team members is reflective of a
productive meeting.

The scheduling of a meeting is another factor that
determines the productiveness of a meeting. Some things to keep in mind are the
duration, location, and time of the day. Daily scrum meetings should be
time-boxed to 15 minutes. The purpose is to keep the discussion short but
relevant. To avoid conflict, meetings should be held at the same location and
time each day. It is also essential to make the meeting time in morning because
it will set the context for the rest of the day's work. Sometimes it is
impossible to follow a strict schedule but it is necessary to develop a
routine. Whatever the case may be, plan the meeting around the team.

Overall, agile meeting are designed to be lightweight.
Being lightweight means that they are well structured and scheduled to be
productive. There will be do's and don'ts. Just remember that every member on
the team is to participate. Providing relevant information to the project shows
each individual's commitment to it.

**Work Cited**

"Agile at Work: Driving
Productive Agile Meetings" Lynda.com - from LinkedIn, https://www.lynda.com/Business-Skills-tutorials/Staying-lightweight/175075/437990-4.html
Accessed 18 Nov. 2017.

**Image provided by**

http://barbaragiamanco.com/wordpress/wp-content/uploads/2014/03/iStock\_000013081344Small.jpg
Creating Personas

Creating and using Personas is an important aspect of
developing user stories. A Persona is an archetype of the average user of a
system and was first developed and introduced by Alan Cooper. A Persona is an
example of a type of person who would interact and use a system or product and
is the type of person the software or product is designed for.

And important distinction to get out of the way first is that Personas are not
Actors who are used in use case modeling. Though they seem similar Actors are
roles that people play in a system. Where an Actor is usually defined in a few short
sentences to describe what part they play in a system, Personas go more in-depth.

For Personas it is not uncommon for a page or two to be
written about them, including information such as their name, Personalities, motivations
and more often than not a photo. This is important because a Persona describes an
archetypical instance of an actor. Where and actor would represent one person,
a Persona would represent multiple actors.

It is important to develop multiple Personas, the number usually
depending on how complex or how big a project is. This ensures that you have
enough to explore all the various needs of the user base for your product. One
way to help think up Personas is to hold a focus group with the potential users
of your project or by talking with people who would have a good idea of what
the end user will be, like your customer support staff.

A few other tips for writing effecting Personas is to
discover them as a byproduct of your requirements investigation process (Personas).
Another technique is to make your Personas specific rather than too general. If
a Persona is too generic, then their needs with shift to meet the moment and
this will not help you. You want flexible software not flexible users. Having
specific goals will also help you see what your system needs to do and what it
doesn’t need to do.

Persona are a valuable tool for anyone developing or writing
user stories. It is very helpful when it comes to narrowing down what your
clients need as well as help you determine what more development time should be
focused on and what can be left secondary or ignored. It is important to make
sure that the Personas vary to meet the different requirement, but make sure
that they are each focused on a specific feature of your product and not
spreading out to try and fit in everything.

Sources:

*Personas: An Agile Introduction,*
www.agilemodeling.com/artifacts.personas.htm
Product Backlog

Product Backlog

                In
Agile it is important that the development team knows what it is doing and what
it is planning to do at all times. This ensures that there is no confusion or
wasted time for the team members as they work on the project and makes it
easier to plan for the release of the product. Because of this a product
backlog is a necessity.

                A
product backlog is a list of prioritized work that is taken from the
requirements and the roadmap and provided to the development team to pull tasks
from going from the most important items at the top, to the least important at
the bottom. One of the most important things about the product backlog is that
the pace is set by the team, not by the product owner. This ensures that the
development team is working at their pace and not overburdened.

                As
stated before the tasks that are on a part of the product backlog are provided
by the roadmap and requirements that would have been acquired well before this
stage in the project. The initiatives of the roadmap are broken down into several
epics and then each of the individual epics will have several user stories and
requirements.

                Once
you have the user stories they are then broken down again and then organized
into a single list for the development team. When provided the epics the
product owner could choose to provide a completed epic first, or several epics
will be required over time. What epics are chosen to be sent in first depend on
a few things such as:

                                Customer
Priority

                                Urgency
of getting feedback

                                Relative
implementation difficulty

                                Symbiotic
relationships between work items (Atlassian)

                As soon
as you finish the backlog you cannot just let it sit there. It must be
maintained regularly as the program progresses. Before each iteration meeting
the product owner should review the backlog it make sure it has the correct
priorities and any feedback has been included into it. There are a few things
to be on the lookout for that may cause the backlog to become unorganized.

The product owner prioritizes the
backlog at the start of the project, but doesn't adjust it as feedback rolls in
from developers and stakeholders.

                                The
team limits items on the backlog to those that are customer-facing.

                The
backlog is kept as a document stored locally and shared infrequently, preventing
interested parties from getting updates. (Atlassian)

                The
product backlog serves as the foundation for the project, and even though it
may change over time, it an important part of the project and is nessisary for
a team to stay agaile and to make the planning easy as well as to make sure the
group stays on track throughout the course of the project until completion.

Source

Atlassian. “The
Product Backlog: Your Ultimate To-Do List The Agile Coach.” Atlassian,
www.atlassian.com/agile/backlogs.
Deciding on Scrum Master

In the Agile methodology a key person involved in the process is the Scrum master. There must be a concise decision in how to choose the right person for this role. The characteristics to look for in deciding the Scrum Master is desire, how much they care for the responsibility and management, and skill . Both are key components in being an ideal choice for a Scrum Master. They must have a knack with dealing with the various aspects of the Agile process. The Scrum master should have a versatile collection of skills that will help benefit any person that is on the team and the desire to finish a successful project.

The Scrum Master must be respected by the team and are a reliable person to ask for help. They are an asset in completing tasks and finishing requirements. Throughout the project a Scrum Master will decide and execute every sprint along the way to a completed project. They should be someone who *wants* to be responsible for this crucial role. It is important to remember that in terms of choosing a quality candidate, they should have passion that will allow them to focus effectively and efficiently. In terms of choosing a scrum master, passion trumps skills.

Someone who should be considered is someone who will not have to be forced to be the Scrum Master. They will want to manage the team in a purely individual way. They should have the technical depth and breath in terms of software understanding. It is important that they remain knowledgeable in any requirements that need to be addressed and should have communication with the rest of the team. The Scrum Master is an important role so the quality of the project will be determined through having a capable and reliable leader to handle the workload.

1. ↑ 1.0 1.1 http://www.jeremyjarrell.com/choosing-best-scrum-master/
Teamwork in Agile

When developing in Agile, one of
the most important, if not the most important thing is having a solid and
dependable team. A good team will be able to work together to solve most any challenge
that comes their way, and will be able to produce a better quality project,
faster than a poor constructed team. While individual performance is important,
for Agile “we” is more important than “I”.

                However
even a team that seems like it would be perfect together takes time to grow.
This may be due to just trying to get to know one another, or to get used or to
establish what kinds of styles you may be using, to just trying to nail down communication
and get it running smoothly. On average an agile group goes through four
stages: Forming, Storming, Norming and Preforming. One a team reaching the
preforming stage, it is at its best with the team able to rely on one another
and to work on each other’s strengths and covers each other’s weaknesses.

                However
even when a team is at the preforming stage and is working perfectly together,
there are still things that can threaten or slow the development of the
project. Something like a new person is added to the team either for a specialized
skill or for whatever reason, or is if something from the team is removed or
leaves. Either way the team is pushed back to the first stage until it can
learn to cope with the change.

                Another
important component of an Agile team is continues mentoring. This is not just
for junior members to learn from senior members. Rather is it something that
the entire team can take advantage of. It allowed the different members to
learn new skills and techniques. This leads into another important component:
shared skill sets. If only one member knows a particular skill, then if they
are removed from the project or miss a day, then it can slow the entire project
or stall it completely.

                Agile
is a very team centered style to project management, and it is important that
the team members quickly learn to trust and rely on each other to allow to project
to run smoothly. It is also important that they can take something away from
the experience and learn from on another so that any delays can be dealt with promptly.
Release Burndown Chart

Release Burndown
Chart

                A
release burndown chart is another way for a project to be tracked in Agile. At
the end of each sprint the release burndown should be updated to convey the
most accurate information of the current state of a project. One of the most
notable features of a release burndown is that the amount of work and sprints
is fixed. There is a set end point and a set amount of work that must be done.

                The
release burndown is a set of points for each sprint and the amount of work for
each point is determined by the team’s velocity. On the graphs vertical axis,
there is the amount of work that must be done, wither story points, or days or
whatever works best for your team. One the horizontal axis is the number of
sprints.

                The
benefits of the release burndown is it becomes easy for the team to see what
they have to do each week and they can exceed the amount for one sprint to make
the next one easier. A sprint burndown can occasionally be altered if new
requirements or work is added or removed. Sometimes a team can work with the
problems but other times the burndown chart has to be altered to account for
the additional work.

                A
burndown chart is a good option for many teams and projects, however it is
important to know that there are different types of charts for different teams.
If a project had its requirements changing often then that team may need a
different chart as opposed to a small project with its requirements well known
at the start of the project. (Cohn)

                A
burndown chart is necessary for any team if they want to keep track of what
work is currently happening and what they can look forward to, as well as how
much progress is made with each sprint. (Cohn)

Source:

Cohn, Mike.
“Release Burndown Chart.” Mountain Goat Software, www.mountaingoatsoftware.com/agile/scrum/scrum-tools/release-burndown.
Planning the release

When planning a release there are a few things that need to happen to have a successful release. An important process that needs to be done is scheduling a release, but to schedule a release the team needs to figure out the product owners deliverable. Just because the agile team has an idea of the deliverable from the product owner, doesn’t mean that the team and the product owner will always be on the same page. So, to “fill the gap”, there is a product backlog, release backlog and the sprint backlogs.

I’m going to explain each backlog in a broad sense so everyone who reads this can have a little understanding of each type of backlog.

“In the simplest definition the Scrum Product Backlog is simply a list of all things that needs to be done within the project. It replaces the traditional requirements specification artifacts.”

“A release backlog is a subset of the product backlog that is planned to be delivered in the coming release, typically a three- to six-month horizon. It would presumably contain the same type of items as on a product backlog.”

“The sprint backlog is a list of tasks identified by the Scrum team to be completed during the Scrum sprint. During the sprint planning meeting, the team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story.”

To sum up, even though agile is a sprint by sprint based process, having a product backlog to keep everyone involved on the same page is very important!

Here is an example of a product backlog and sprint backlog.
Key Characteristics of Agile Reporting

One factor that distinguishes Agile from other project
management methods is that Agile works to display the truths of a project
through easy-to-understand images (Rose). Instead of focusing on intricate
details, Agile requires project managers to view individual reports together as
a big picture that describes a project’s health (Rose). The benefit is that
this allows for Agile reporting to be **transparent**.
Transparency can be defined as “open, direct communication in Agile projects” that
allows any team member viewing the report board to be able to identify the
project’s successes and problems (Rose). Being transparent about problems often
proves to be difficult under traditional project management. However, Agile
does not allow teams to hide their issues. Reporting with Agile charts will
inform the organization if the team is overestimating the value of their
accomplishments as they compare to the problems still in need of fixing. If a
product owner finds that the team is being “too optimistic,” they can change
priorities or cancel the work (Rose). Transparency in Agile reporting is
crucial because is builds trust between the team and the product owner (Rose).

Furthermore, Agile reports should all contain two
traits: **Simplicity** and **visibility** (Rose). This is necessary
because it gives numerous participants access to the project, which in turn,
creates “good feedback loops between the team and the customer” (Rose). A
common chart that demonstrates simplicity and visibility is the burndown chart
(Rose).

A burndown chart is a line graph (like the one
displayed) that will show whether a project will be delivered on time (Rose).
Burndown charts can be used with each sprint and serve as information-givers
(Rose).

(Image from: http://eforexcel.com/wp/download-template-03-an-felxible-agile-burndown-chart/)

A team’s task board is another simple report. The task
board works to show the project’s user stories and tasks on a board or a wall
(Rose). The task board is simple enough that those unfamiliar with Agile, like
a manager, can understand how the team is progressing (Rose).

(Image from: https://www.pinterest.com/explore/scrum-board/)

Lastly, one of the most significant reports is the
product backlog (Rose). The product backlog is “a simple list of user stories
ranked by value” with the highest valued stories at the top of the list (Rose).
The product backlog is used by the product owner to display what he or she
feels is the most important work and should be used in most meetings to foster
the team’s understanding (Rose).

(Image From:
https://www.smartsheet.com/agile-project-management-excel-templates)

**Works Cited**

Rose, Doug. “Keeping
Agile Transparent.” *Lynda.com - from LinkedIn*, 23 Nov. 2015, www.lynda.com/Business-Skills-tutorials/Keeping-agile-transparent/175962/452757-4.html.
Retrofitting and Reworking in Agile

Sometimes in agile, the formatting and process of new documents and files are
too dated for the current project.  The
team has to then rework and retrofit the documents to make them better suited
for agile.  It is not recommended to
retrofit old documents, so if possible try to avoid it and create new documents
using existing charts and reports.  Transitioning
to an agile framework will end up being a pitfall but sometimes those documents
can be adapted to meet the current requirements.  These can be a separate from the existing
documents and can provide more leniency when switching to agile.

A charter can be transformed to rework existing pitfalls in
the system.  The milestones become
high-level epics that the product owner can commit to delivering.  As opposed to having a product manager the
agile team can be self-organized which means one person doesn’t know everything
about the project.   You can either
rework to fix part of the product or retrofit to rebuild part of the
product.  This adds a new level of
quality in the development of the project.

Traditional agile practices avoid both reworking and
retrofitting as it hampers the efficiency of the team.  As the team moves forward and encounters
problems they have the ability to deal with it or may have to spend more hours
in the solution.  Sometimes a project
manager may have to discuss the project’s flexibility and if the changes are
capable or not.  The project schedule may
be the hardest to retrofit.  The schedule
is a tool to deal with a thoroughly planned project.  The product owner and manager should work
closely in retrofitting the documentation with creating high-level milestones.

Through the triangle
of responsibility there is equal share in how to retrofit the project’s
documents.  The reports made by the
project manager, the product owner will still have some ability to change the
organization, and the scrum master protects the project’s framework.  Through this retrofitting can be useful in
project management, so long as it does not make the team less agile.

# Citations

Rose,
D. (2015, November 23). Retrieved November 27, 2017, from
https://www.lynda.com/Business-Skills-tutorials/Retrofitting/175962/452774-4.html

Hertzfield,
J. (2006, July 12). Retrieved November 27, 2017, from
http://it.toolbox.com/blogs/alm-blog/agile-rework-and-retrofit-10467
Common Mistakes Made When Writing User Stories

Getting
user stories correct is a crucial part of a project. The following are common
mistakes teams make when writing user stories.

role is not too specific. Having a too narrow focus will make the story not applicable
to enough of the customers.

### **Not collaborating on user stories**

Collaboration
is a significant part of writing user stories. The product owner and the
development team should work together to pinpoint what features the customer
would want. This should be done by meeting regularly every time a new
functionality is released. This saves time by resulting shorter release cycles
and enhancing build quality.

### **Expressing everything as a story**

User
stories are an important part of the project, but expressing everything as a story
is a mistake. Doing so usually results in stories that focus on project aspects
such as “user interface design, complex user interactions, and technical
requirements.” These would be better described through methods such as sketches
and storyboards. User stories are best when focused on product functionality
and nonfunctional requirements. Your team should feel obligated to always use
user stories

Works Cited

Choudhary, byNidhi. “7
Common User Story Mistakes and How to Avoid Them?” *TO THE NEW BLOG*,
12 May 2017,
www.tothenew.com/blog/7-common-user-story-mistakes-and-how-to-avoid-them/.

Pichler, Roman. “5 Common
User Story Mistakes by Roman Pichler.” *Roman Pichler*, 31 Jan. 2017,
www.romanpichler.com/blog/5-common-user-story-mistakes/.