recursal/Fanatic-Fandom huggingface dataset:
History of Project Management

History of Project Management

Project Management may strike one as a recent buzzword, however the concept has been around for thousands of years. The history of project management dates back to ancient Egyptian times where projects such as building pyramids required the managing of scope, materials, budgets, and workforce to create deliverables in a timeframe.

Fast forward to the early 20th century, we have a person named Henry Gantt who created a chart to show complex project schedules. The chart today is known as a “Gantt” chart and is widely used in Project Management. Project Management continued to evolve as more and more things were added. Frederic Taylor an associate of Henry Gantt introduces theories of management. His theories made tasks efficient by using fine tuning techniques. Other methods of scheduling were also developed such as Program Evaluation Review Technique (PERT) and The Critical Path Method (CPM). PERT scheduling charts analyzed tasks to identify the minimal amount of time required to completing a project. CPM is an algorithm for scheduling project activities where it list all activities required for a project, the length of time for each activity, and any dependencies between the activities. Although these methods of scheduling are not exactly what is found in modern society, Project Management still remains as the process for overlooking the planning, organizing, and implementing of a project.

In modern day, we heavily integrate new technologies into our projects and the tools that manage them. Examples such as the internet and computers greatly help us discover risks and increase efficiency of our work. The project management process lifecycle tends to follow the general structure of gathering analysis about the requirements and resources needed to complete the project. Developing the architectural design, executing the implementation followed by finalizing and maintaining the project are all part of the structure. Strategies in project management differ in workloads and rates at which the steps are individually completed. With such technologies, the project management process stays relatively the same, but new tools and devices help teams produce a much improved final product.
Incremental Delivery

In agile, work is broken
up into short bursts of work known as iterations. These are often known as
sprints in scrum. Each sprint is focused on producing a single deliverable as
apposed to traditional project which focuses on a single release at the end of
the project’s timeline. Agile is focused on always delivering something that is
improved incrementally. A waterfall project is completed in some number of
phases. In the first phase some foundation is set. In the second phase that
foundation is then built upon according to whatever requirements were gathered
for the project. In the final phase, the project is then finished off with it’s
most important features and then delivered. In agile, the project is worked on
in smaller more manageable pieces. The team might decide to work on whichever
part of the project is most valued by the product owner. So that part has the
foundation built, improved, then delivered all in one sprint. In each
successive sprint the next most valuable part of the project is produced and
delivered, with each sprint producing something that works. This gives the team
the advantage of having a completed deliverable each sprint along with much
more flexibility than traditional project management.

If after seeing how the deliverable of one sprint
performs, either over or under-performing, you can change the direction your
project is going on the fly. So if after the first sprint you find the initial
plan was producing something that would not have much value you wouldn’t be
stuck spending all your resources producing something that will end up being a
waste. Sometimes the traditional project would end up with a product that
couldn’t even be delivered. Traditional project management may seem like a more
natural way when first thinking about how to plan a project. It’s even one of
the biggest difficulties encountered by newer agile teams. This is not only a
way to split up a project’s workload but is a different way to approach
delivering the work.

Sources:

"Agile
at Work: Planning with Agile User Stories."
www.lynda.com/Business-Skills-tutorials/Agile-Work-Planning-Agile-User-Stories/175074-2.html.
Accessed 11 Nov. 2017

Image provided by:

http://www.restfinance.com/Restaurant-Finance-Across-America/June-2017/Test-Suggests-Delivery-Apps-Provide-Incremental-Sales-not-Cannibalization/
Building A Team: Defining the agile team roles

Defining roles in agile teams

An important part of project management in a agile
environment is building a team. While team building may seem simple, it deal
more than just gathering people. There is a whole process in agile for this. By
understand what agile is and how it is applied in building a team, this can be
crucial for the success of a project. The Scrum framework defines the agile
team roles into three formal roles known as the product owner, the developers,
and the ScrumMaster. Reviewing these three roles will allow for a better
understand on how to build a team.

The role of the ScrumMaster in an agile team is very
practical. While a traditional project manager will control how the team
delivers a product, the ScrumMaster only fosters the team by coaching and
training them. As the ScrumMaster who has mastery the Scrum framework, they
understand the importance for a team to be self-organized. Through restraint,
the ScrumMaster can focus their time on removing obstacles and ensure a great
working environment for the team. A ScrumMaster who is capable of fulfilling
their role will provide the team with greater self-organization.

The role of the product owner is one of the most important
on the agile team. They are the powerhouse because they represent the customer.
Their direct communication with the customer allows them to have a final say in
what gets done. As the product owner, one of their main roles is to maintain a
product backlog which is used for prioritizing work. The product backlog
contains all the features that the customer wants in the final product. The
product owner must deliver the product in a way that satisfies everyone.

The developers role in an agile team is the most
versatile out of the three formal roles. Developers are the core of projects as
they are the true knowledge. They work on delivering the product to the
customer. Since agile teams are cross-functional, developers are not limited to
just software coders. The developers can include graphic designers, software
test, and even database specialist. Although they are group together under
developers, each are responsible to help produce when able. Developers are
consider to be self-organized, and have a good mix of skills to perform task of
others.

**Work Cited**

"Agile at Work:
Building Your Agile Team." Lynda.com - from LinkedIn,
www.lynda.com/Business-Skills-tutorials/Welcome/175073/379413-4.html. Accessed
1 Nov. 2017.

**Image provided by**

http://milindageorge.files.wordpress.com/2013/03/a468-f1-scrum-team2.png
Agile at Work/ Driving Productive Agile Meetings -2A- Planning the release schedule

Unlike many projects that come together in the end for a grand unveiling, Agile methodology is able to deliver working aspects every sprint, slowly building up the product bit by bit. With a product owner prioritizing work during each sprint, the team does not need to worry about a customer that can’t really define their project. Over time, the product owner can  direct new features and improve the strategy each sprint. Expectation gaps are formed the agile team delivers something that is inconsistent with what the organization seeks, and to remove this gap, teams can utilize the product, release, and sprint backlogs.

Each of these backlogs can be expanded on with the assistance of the customer where they can give flexibility and insight where they see fit. To give the organization stronger commitments to sprint deliverables, the release backlog is used to come to an agreement with the product owner on suggested changes. From there, the owner can go from the product to the release backlog and put a hold on any substantial changes. Further changes can be locked completely with the sprint backlog, where items are always set. But as a team, and specifically the scrum master, everyone should be aware of the problems that can occur by relying to much on each backlog, and should be always communicating with the product owner.

Another technique for scheduling a team release is to make a ROVe release date, which acts as a rough order of value for a project.  A positive to this choice is that it helps the organization stay committed to working with the value of a deliverable that Agile methodology can ensure. Things can still be altered during this development, but planning with ROVe will keep the team focused on the end result.

Being able to change and discover is the strength of agile, and using any of these techniques can give freedom to organizations and teams. Some may relinquish more flexibility and insight to final implementations as long as teams come to an understanding and compromise. Others may want to hand over freedom to a product owner to bring the highest product value, and for this they may want to choose a ROVe release schedule. Any of these choices can help a team, it just comes down to what each is willing to handle to the best of their capacity.

Works Cited

"Planning the Release Schedule." *Lynda.com - from LinkedIn*, www.lynda.com/Business-Skills- tutorials/Planning-release-schedule/175075/437994-4.html. Accessed 17 Nov. 2017.

Image Link: https://visualpharm.com/assets/353/Schedule-595b40b75ba036ed117da0d7.svg

Image Link: https://www.jetbrains.com/youtrack/img/convince-manager/icon-cards\_\_papers.svg
Building A Team: Confusing roles

Confusing Roles

To further elaborate on roles in an agile team, designated
roles can often be confusing to fulfill if they are not properly understood.
Agile team roles are broken down into three formal roles which includes the
ScrumMaster, the developers, and the product owner. Each role will have
specific focuses that is crucial to the success of a project. A team that has
never been dealt with the agile framework will find it hard to adjust because
of legacy habits. To help clarify roles in an agile team, the following
paragraphs will provide details.

Although it may seem like the project manager is in
charge, it is the developers who are responsible for the delivery of a product.
Simply put, the developers will work directly with the product owner to
breakdown high value work and create estimates of work completion. Developers
make a majority of the decisions for the project even though the product owner
will have a final say. As the developer, it is important to maintain being
self-organized for increasing productivity. Their primary focus is the delivery
of a product to the customer.

As the ScrumMaster, this role states that designated
person has master the agile framework. The ScrumMaster is to foster a great
working environment and remove obstacles blocking a team from being
self-organized by following the agile framework. It is not the ScrumMaster's
duty to keep an agile team moving. If there are any problems with developers in
making good estimates, the ScrumMaster will coach and train. The primary focus
of a ScrumMaster is on the team and training them correctly in agile.

Lastly, the product owner role is very important because
it connects the agile team with the customer. The product owner will
communicate with the customer to gather requirements for the product. This
information is given to the developers so that they can build the estimation
for completing work and delivering the final product. The direct communication
ensure that developers are working towards the desires of what the customer
wants in a reasonable time frame. The focus of the product owner is to bridge
requirements to a final product.

**Work Cited**

"Agile at Work:
Building Your Agile Team." Lynda.com - from LinkedIn,
www.lynda.com/Business-Skills-tutorials/Welcome/175073/379413-4.html. Accessed
1 Nov. 2017.

**Image provided by**

https://image.slidesharecdn.com/rolesresponsibilities-5-24-rt-150120195218-conversion-gate01/95/agile-roles-responsibilities-4-638.jpg?cb=1435775036
Building A Team: Training an Agile Team

When trying to bring Agile into an organization, one should start smaller rather than larger. Following the Agile framework can be done much easier with smaller core teams, and expansion within the organization done by exposing other groups to this methodology naturally. With one team understanding and running Agile, they can then teach and introduce Agile to all other teams. It should be known that the first team to learn and integrate Agile, should be the most knowledgable and proficient at using such methodology. This team acts as the core and becomes the strongest voice to motivate change, and as such, should be given ample time to be successful and the ability to see the positives of said transformation.

The biggest roadblock to an Agile transformation is the success or failure of being able to covert skeptics and make sure they are on board with the new methodology by eliminating bad training and information. Making sure the core team understands all that goes into this integration can stop the spread of bad information and nip it in the bud early on. This core team needs careful training to stop any future retraining that can cost money, time, and any other resource necessary to fix problems that inhibit success.  The two things this core team should be most concerned about is making sure everyone on board understands the rules of agile while giving them a place to talk about any problems, concerns, or doubts about such a transformation. This should all be talked about during the training period, and should be covered if the organization hires a good certified trainer who is not scared of team members asking tough questions.

Investing in a great trainer and focusing resources to training a core team can reap only positive rewards. The key is helping the core team begin the training process and project with good tendencies and removing all bad ones before they have a chance to grow and spread to other groups. Getting the team energized and performing the Agile methodology properly can make a great impact on the rest of the groups within the business and organization. Pushing for face-to-face communication is something that can work for the entirety of any agile project and encourages collaboration. Making sure the team understands what can make a project successful, and having certain expectations, can all be done by increased communication and group collaboration.

Works Cited

"Agile at Work: Building Your Agile Team." *Lynda.com - from LinkedIn*, www.lynda.com/ Business-Skills-tutorials/Welcome/175073/379413-4.html. Accessed 1 Nov. 2017.
Updating the Task Board

There are many
techniques that help agile teams stay coordinated such as, Pair Programming and
Scrum Meetings. However, one often overlooked yet vital component is the task
board. Even in some scenarios where agile teams are implementing task boards,
developers or other team members often will not always reflect all the work
they’ve done onto the task board. Other members might not want to participate
in initializing and organizing the task board. It is up the scrum master to help
enforce that everyone is performing the proper task board procedure.

The task board modifications begin during the spring
planning. The agile team will come to a consensus on the stories for the
current sprint. After all stories have been created and agreed upon the agile
team will then prioritize the stories from top to bottom (any order works, just
make sure the entire team is on the same page).  The next step is for the team is to create the
tasks. Each task will be written on a sticky note (usually yellow) and should
be aimed to resemble a day’s worth of work.

After stories and tasks have been created and set, no one
should be updating the tasks except for the developers. When anyone has the
authority to move and alter tasks, it becomes very hard for the programmer to
keep up with what they are working on. At the start of each sprint the team
will decide which stories it wants to complete for that sprint and generate the
appropriate tasks in a to-do column. It is during each morning stand up that
these tasks can be moved from the to-do column to the doing column. Another
thing to keep in mind is that during each daily stand up every developer should
be updating the board. This flow is generally easy to keep if the agile team is
good about creating appropriately sized tasks.

Often developers will want to combine tasks, or just knock
out an easier one after they finish a different task. It can be very tempting
to think, ‘Oh that one is really easy too I could knock that out in 30 minutes
tops’. The problem can occur when multiple developers adapt this same mindset
and might all pick up the same tasks, without updating the task board. Another
problem developers run into in this scenario is when tasks turn out to be more difficult
than they thought, which happens a lot. One might think this extra task will
just take up 20 minutes of their time. Two hours later they finish to find out
someone else has begun working on it.

It is very important for agile teams to implement a good and
meaningful task board to stay organized. However, just initializing a good task
board isn’t enough. Agile teams must constantly update and reference their task
board in an orderly and controlled fashion. It is good practice to never start working
on anything new unless the task board has already reflected such a decision.

Work Cited:

"Agile at Work: Reporting
with Agile Charts and Boards." https://www.lynda.com/Business-Skills-tutorials/Updating-taskboard/175962/452765-4.html.
Accessed 27 Nov. 2017.

Image Provided By:

https://manifesto.co.uk/agile-concepts-scrum-task-board/
Set goals using SMART criteria

A common mistake for beginner agile project teams is to not
the devote the sufficient attention and severity to retrospective meetings.
Retrospective meetings will often assume a very relaxed vibe, such as a small
office get-together. When this happens, team members will typically chit chat
about irrelevant topics to the project or just discuss unimportant project
matters. Retrospective meetings should come with a bit of relief but still be
very productive with a disciplined agenda. The true goal of retrospective
meetings is to identify challenges and highlight opportunities.

During retrospective meetings team members will collaborate
to generate action items. These actions items are aimed to help improve the
process. After creation of the necessary action items, teams will begin to set
goals that will result in project improvements. While setting these goals team
members should try to not think too abstractly and instead focus on smaller,
more achievable tasks. Peter Drucker, a management guru, helped design the
acronym SMART. SMART provides criteria to help assist agile teams develop efficient
and meaningful goals.

When team members each develop their action items, each item
should be tested against the SMART criteria. There are five essential questions
that the SMART criteria really ask about, “Is the item specific? Is it
measurable? Is it achievable? Is it relevant to the project? Is it time-boxed
to something possibly achieved in a sprint?” If action items can generate a yes
to all five of these questions then that action item will more than likely
produce improvement for the project.

One of the most frequent errors when creating action items
is allowing the item to lack in specificity. Possibly the agile team is having
issues with ‘challenge X’ and they want to create an action item labeled ‘improve
team X’. Having a broad scope such as ‘improve team X’ might be sufficient
enough for a team discussion, however for an action item it does not provide
enough direction or context. A big help can be to try and include the ‘how’ in
the title of the action item. A label like ‘improve team X through workshops Y
and Z’ paints a much clearer picture of what results to expect from the action
item.

There are many aspects about retrospective meetings that can
be overlooked and its important for agile teams to make the most out of these
meetings. Retrospective meetings provide an opportunity for teams to generate
and tweaks action items and goals that help drive the product towards a
successful completion. SMART is a technique that assists teams in helping
assure that their action items and goals are short and effective. Goals should
start and end in the same sprint, they should not drag on through multiple
sprints.

**Work Cited:**

"Agile at Work: Set
Goals Using SMART Criteria." https://www.lynda.com/Business-Skills-tutorials/Set-goals-using-SMART-criteria/175961/468248-4.html.
Accessed 4 Dec. 2017.

**Image Provided By:**

https://www.readyartwork.com/applying-smart-goals-future-success/
Agile at Work: Planning with Agile User Stories -Creating your project charter, Using relative estimation

Creating a project charter is a great  way to understand the project direction as a whole. But there are always some things an organization will want to understand to deliver a successful project charter, and ultimately, the project itself. Charters should contain criteria for success and an overall mission, with an integral component being that of adapting to bring forward value and not trying to predict value before the project beings. Project teams need to make sure they know the difference between the vision of the project being met and team success. Project charters within the Agile framework should be something that is agreed upon and not a plan that needs to be carried out. Every component of the project should be listed by what each group wants to be delivered, and the customer should create a formal charter to push the team in a beginning direction.

With charters, we need to understand that this does not mean things will not be changing, but instead, it helps the team brainstorm and jot down ideas at the inception of the project. In order to close a project, these project charters become extremely important to execute. The only way for a customer and team to fully check all the boxes that consider a project fully delivered is to have the agile team create a retrospective meeting where members can take down all lessons that have been learned from the agile process. Proper and successful project charters should be roughly one page of content with only three major sections: success criteria, vision, and the project mission.

When using relative estimation, teams will use time measurements such as hours, days, and weeks. This measurement can often become more of a focus than an ability the team may have with understanding what work is to be done, and as a result, team members will usually estimate using ranges of time. These estimations are not made to be accounted for exactly, but instead, give means to create a dialogue about what is needed to deliver stories. There are many reasons agile teams use this type of estimating, but the main two are: a false satisfaction of precision, and it keeps the agile team from blurring assessments from needs. These relative estimates gives the team the ability to get right to work and prevents members from losing time discussing how long any specific task might take.

Works Cited

"Agile at Work: Planning with Agile User Stories." www.lynda.com/Business-Skills-tutorials/ Agile-Work-Planning-Agile-User-Stories/175074-2.html. Accessed 10 Nov. 2017.

Image link: https://usercontent2.hubstatic.com/13342829\_f496.jpg
Jigsaw (Terror)

Jigsaw to potwór z filmu piła. On jest lalką. W filmie robił brutalne tortury na ludziach. W GTA pojawia się w modzie Terror Mod. Znajduje się w Verdant Bluffs. Z nim są też dwie świnie z piłami mechanicznymi. Te dwie świnie są podobne do Piggsiego. Jego bronią jest nóż. Słabością Jigsowa i jego świnek jest broń palna.
Agile at Work: Planning with Agile User Stories - Planning Poker, Velocity

A strategy used by many agile teams is called ‘Planning Poker’. This card game allows agile teams create the best estimates of stories without the need for ideal and expert information.

When playing ‘planning poker’, it takes assumptions that all team members are experts that will not be able to come to an agreement on time measurements for each story deliverable. This game takes into account the entire team’s knowledge and gives each person their own voice in the project.

With this approach, the team will make estimates for the team in it’s entirety rather then for single team members, and these estimates become more of a bi-product to the game. The goal is to dispel the concept of ‘group-think’ in which people will just agree with whatever the most popular idea is, with the loudest voices killing any disagreement. ‘Planning Poker’ is a simple game that is accurate with agile planning, where each team member will make their estimate in story points rather than hours, before anyone is told what the other is thinking. As a team, they will then discuss one smaller story and assign a value of two, becoming the estimation baseline -the relative estimate’s first half. After that, other stories are then brought out from highest to lowest value via the product owner, with the story being read to the team for them to start estimating immediately. Each member of the team will then estimate by choosing a card face down, with estimates representing a number that includes risk, complexity, time, and other important factors they can think of. After all members are ready, each card is flipped at the same time, in hopes they can come to an agreement, recording the number and size. Once this is completed, the team can move onto the next story repeating the same actions. The ‘Planning poker’ game is one the most important parts of making sure that everyone is included in the estimation phase, giving each person their chance to defend their estimation.

After this game is played, the team can try to understand the velocity of the agile project. Team members will see how much they have worked and to what extent they are committed to future work. This is usually calculated by the project scrum master by creating a number based on the amount of story points the team was able to deliver during each sprint. The velocity has the ability to increase and decrease based on how the team performs during sprints, and it is often abused by senior managers who overextend their employees, bringing down the quality of work to increase the pace. With velocity, it is good to respect the team members and give them manageable workloads that can deliver quality work on time each week, and since these numbers are ultimately created by the team, anyone outside trying to change this number can make the team less useful in the long run.

Works Cited

"Agile at Work: Planning with Agile User Stories." www.lynda.com/Business-Skills-tutorials/ Agile-Work-Planning-Agile-User-Stories/175074-2.html. Accessed 10 Nov. 2017.
A common pitfall of agile

One of the most common pitfalls of agile development is not
conducting any planning. While there is certainly less planning in agile than
other methodologies of development, planning is still essential to a successful
agile team. Planning in agile is conducted in a different fashion than
traditional project management strategies. When making the transition from more
traditional management strategies, such as plan and document, to agile, it is
easy to find yourself trying to plan everything or forgetting to plan all
together. The planning rules and guidelines certainly exist in agile, they just
tend to be much more lightweight. However, it should be noted that because
there are much less *rules* in agile
planning, the rules that are in place should be followed with great
consideration.

When learning agile you might hear a lot of qualities that
sound similar to the story of Goldilocks. For instance, in agile you don’t plan
nearly as much as you did in prior strategies, but you also don’t omit planning
all together. It is all about finding that middle ground of planning that is
sufficient enough to serve its purpose while not taking away from productivity
that could be spent delivering software. It’s quite difficult for anyone who is
relatively new to agile to have an understanding of where that nice middle
ground is.  This dilemma is where a good
scrum master can really benefit an agile project.

The loosely defined framework of agile allows for teams to
elastically respond to change whenever needed, but it can also give the power
to the agile team members to abuse this loosely defined nature. It holds true
for almost all developers that they would rather develop code opposed to
generating documentation, it’s just the nature of the job. A scrum master must
make sure that team members are not abusing the agile process by making their
own process changes. In the end, agile was created to help teams deliver
software and not to allow team members to dictate how and what they complete.

In summary, agile provides a framework that is optimized for
coping with the flexibility of a project. This is not the same statement as
agile is a free ticket that lets deliver the product however the teams choose.
It is imperative to not mix up the term agile with how a team conducts their events.
If your agile team finds themselves constantly altering the agile framework
itself, then chances are your Scrum Master is not doing their job correctly.

Planning with Agile User Stories." www.lynda.com/Business-Skills-tutorials/Avoiding-We-dont-plan-were-agile/175074/387225-4.html.
Accessed 13 Nov. 2017.

**Image Provided By:**

https://medium.com/great-products-dont-happen-by-accident/great-products-dont-happen-by-accident-f46323d8ad94
Breaking the Sprint

When teams are using agile for a longer period, they become
more experienced with agile and familiar with their team members. When teams as
a unit become more experienced, sprints become more efficient while the amount
of work assigned for each sprint will gradually become tailored to the perfect
amount. However, reaching this Goldie-Locks amount of work for each sprint is
only achieved through trial and error. Sometimes an agile team may decide, for
a large number of possible reasons, that they can no longer deliver the work
they committed to at the beginning of the sprint. When this is the case the
team typically will end the sprint early, often referred to as ‘Breaking the
Spring’ or even ‘Abending the Sprint.’

One of the most obvious reasons a team may not be able to
complete all work that had been committed at the start of the sprint would be overcommitting
on the amount of work. This is a common occurrence in newer agile teams. Another
common occurrence with inexperienced agile teams is under-committing to the
amount of work, which is safer than trying to plan out too much work to do. The
prediction of amount of work to be completed is a controllable variable that
tends to become less as a problem as time goes on. Other non-controllable
variables may break a sprint as well. Such as, team family member emergencies,
3rd party technology failures, natural disasters, and even major
product backlog re-prioritizations.

When one of the highest priority items on a product backlog
list gets removed or transformed, it can affect the overall goal of the sprint
so greatly that continuing to work on that sprint would no longer benefit the
project at all. This scenario is often caused by the product manager having a
misunderstanding on a requirement. The product manager will then communicate to
the team the change in goals (and apologize for their misunderstanding). At
this point the scrum master should jump in and remind the product manager that
agile does not support such modification and that the smart thing to do would
be to blow up the sprint and start a new one the next day.

Keep in mind that blowing up a sprint will generally cause
all work during that sprint to become lost. This causes the projected finish
date of a project to be pushed back as well as all sprints and tasks that come
after the broken-up sprint. All because a team runs into a substantial issue
does not mean that they should automatically break a sprint. Sprints should
only be stopped and thrown out if the goal of the sprint no longer benefits the
overall success and completion of the project.

Work Cited:

"Agile at Work: Driving
Productive Agile Meetings." https://www.lynda.com/Business-Skills-tutorials/Breaking-sprint/175075/438009-4.html.
Accessed 20 Nov. 2017.

Image Provided By:

https://softwareengineering.stackexchange.com/questions/304711/what-happens-if-sprint-goal-is-not-met
Planning User Stories: Starting with user roles

User Roles

Writing user stories is an important aspect for
understanding customer requirements. In agile, the focus of user stories are
more than just writing about requirements but to also talk about them. Before
you can start writing user stories, you must start with user roles. It is
essential to know who to write the user story for. The initial requirements are
gathered from the customer by the product owner. These requirements are often
different from a traditional project in which it will focus more on  the user's experience rather than what goes
into creating that experience. The best way to focus on user experience is to
create user roles.

A user role is more than just a person and their
experiences. It is a bundle of user experiences from multiple user roles. For
example, a website could have a user role called visitor. The visitor would be
considers a user role of someone who has landed on the site but not logged in.
There could be another user role called customer that makes purchases from the
site. Furthermore, a customer could be broken down into more user roles such as
a standard customer or a premium customer. The bundle of user experiences is
better explained when a visitor can be seen changing user roles. A visitor who
has registered will now become a standard customer. A customer that wants more
features from the website would upgrade to become a premium customer. One
person was able to experience three distinct user roles based on what they
wanted to do on the website.

In Agile, it is the product owner who creates all the
user roles for the project. Creating user roles
can be a rather challenging task because the product owner must
understand the differences between user roles as they are created. The product
owner would have to come up with bundle experiences on how someone would
interacts with a final product. Questions that the product owner may ask
themselves is what makes a visitor different from a customer? or is it
necessary to divide a customer into separate user roles such as standard or
premium? Tough question like these may not present a solution for the product
owner. Sometimes it might be easier for the product owner to think about the
context, character, and criteria of user roles.

Context, character, and criteria provides a means to
breaking down user roles into much simpler bundle of experiences. Context is a
person's experience based on their place in the website. For example, a
standard and a premium customer will not have the same experiences as the
context for each will be slightly different. Character is the experience that a
person might expect during their interaction with the website. Lastly Criteria
is experiences based on expected outcomes. Overall, creating user roles is the
stepping stone that must be complete before writing user stories.

**Work Cited**

"Agile at Work:
Planning with Agile User Stories" Lynda.com - from LinkedIn, https://www.lynda.com/Business-Skills-tutorials/Starting-user-roles/175074/387212-4.html
Accessed 10 Nov. 2017.

**Image provided by**

cdn.elegantthemes.com/blog/wp-content/uploads/2014/01/user-roles-thumb.jpg
Being Predictable in Agile

Many executives come from
a background of managing a project in a traditional style. These people are
often influenced to produce multi-year and their traditional roots may leave a
desire to establish long-term milestones for these long projects. Agile may not
have much appeal to these executives. They want to be able to have
predictability for their projects so they could plan ahead as they may be used
to from previous project experience. To contribute to this desire of
predictability, agile produces a working product with each sprint. This is
something that these executives can rely on.

In traditional project management, everything goes
according to a plan. For example, if a company wants to create some new
software then an executive is given money to deliver that software. Budgets,
timelines, milestones, and such are then created to flesh out how the software
will be created from start to finish. However, if there are issues with the
plan then some of the previous planned and the software ends up taking more
resources than initially planned.

If an agile team was given a project for creating
software for its company, there wouldn’t be a detailed outline or milestones
established. Instead the team would be working with just the deadline that they
established with their product’s owner. Of course during the project’s life
cycle there will be difficulties such as relying on unreliable sources or having
to make changes here and there. However, the team will be able to work with a
functional piece of software that improves over time with each sprint.

Instead of relying on one plan to follow through one over
a lengthy period, it may be better to work with something that delivers bit by
bit. This is where the predictability in agile comes from. You know what you have
and what works with each sprint. There isn’t always a detailed plan to work
with but instead just a deadline. This doesn’t solve all the problems with
project management, but it does give a very different approach from a traditional
view.

Sources:

"Agile
at Work: Planning with Agile User Stories."
www.lynda.com/Business-Skills-tutorials/Agile-Work-Planning-Agile-User-Stories/175074-2.html.
Accessed 11 Nov. 2017

Image provided by:

http://syscolabs.lk/category/blog/project-management/
The 5 Whys

Finding ways to improve
the process is one of the objectives during a retrospective. Finding what
should have been

done, or what should not have been done, and so on. Once you
figure out what these things were the next step is to figure out how to improve
on them for future projects. A good technique for this is called the 5 Whys
Technique. This technique can be used to found what the original problem which
can sometimes be hard to get back to. This technique is also fairly simple to
understand.

Quite simply, you just need to ask “Why?” 5 times. The
first Why is always the easiest. As you move on with each iteration of asking “Why?”
you might find that it starts getting more difficult to answer than before. The
first “Why?” might give you a quick answer and be related to a problem that
happened most recently. For example, if your car broke down, the first answer
might be that the battery died. On the second iteration you have to answer “Why
did the battery die?” As you might already see, this will get increasingly
difficult to answer. By the fifth time you ask “Why?” you might have an answer
such as “I didn’t properly maintain my vehicle” or something similar to that.
This answer would be a root cause of the problem. The root of the problem is
what you want to find as that is what you need to correct to truly prevent the
issue from happening again.

This technique is a good thing to use when something just
doesn’t seem to make sense. It’s also useful for the facilitator of this
technique to be someone that is outside of the team. If the technique is used
within the team, you might have difficulty with looking at the problems from
varying view points. Since the team always works together and faces similar
problems together. Someone from outside of the team will likely bring in a
fresh view point. The fresh view point is definitely something that will assist
in the team finding new and better answers to “Why?”

Sources:

"Agile
at Work: Getting Better with Agile Retrospectives" https://www.lynda.com/Business-Skills-tutorials/Agile-Work-Getting-Better-Agile-Retrospectives/175961-2.html
Accessed 4 Dec. 2017

Image Provided by:

https://www.workhappynow.com/2010/02/how-to-use-5-whys-discover-true-needs/
Penny Fitzgerald

**Penny Fitzgerald** ist eine der Nebenfiguren in Die fantastische Welt von Gumball. Gumball und Penny waren schon immer ineinander verknallt, aber die beiden hatten sich immer Mühe gegeben, ihre Gefühle unter zudrücken, bis er endlich seine Gefühle gestand und sie küsste. Die beiden sind seitdem zusammen. Sie ist derzeit im Cheerleader-Team der Schule und im Synchronschwimmen-Club.
¿Qué es un gen?

## Gen

### Etiqueta

Partícula de material genético que, junto con otras, se halla dispuesta en un orden fijo a lo largo de un cromosoma, y que determina la aparición de los caracteres hereditarios en los seres vivos.

Se conoce como **gen** a la **cadena** de **ácido desoxirribonucleico (ADN)**, una estructura que se constituye como una **unidad funcional**a cargo del **traspaso de rasgos hereditarios**. Un gen, según los expertos, es una serie de nucleóticos que almacena la información que se requiere para sintetizar a una macromolécula que posee un rol celular específico.

El gen, como unidad que conserva datos genéticos, se encarga de transmitir la **herencia** a los**descendientes**. El conjunto de genes pertenecientes a una misma especie se define como **genoma**, mientras que la **ciencia** que lo analiza recibe el nombre de **genética**.

La tarea de los genes es muy compleja. Esta secuencia de **ADN** es imprescindible para lograr que el **ARN funcional**pueda ser sintetizado. La transcripción genética produce una molécula de **ARN** que luego se traduce en los ribosomas y genera una proteína. Hay genes, sin embargo, que no son traducidos a proteínas y que cumplen otros roles en forma de **ARN**.

Resulta interesante tener en cuenta que los genes que, por procesos de mutación o reorganización, dejan ser funcionales, se denominan **pseudogenes**. Estos pueden contribuir a la evolución de una **especie** ya que su **ADN** acepta mutaciones y puede generar nuevas funciones.

Los **organismos diploides** poseen dos pares de cromosomas homólogos. Cada bloque procede de uno de los progenitores. Además, cada par de cromosomas posee copias de cada uno de los genes (es decir, una del progenitor y otra de la parte materna).

Los genes también inciden en el desarrollo de **enfermedades**. Una variación en su secuencia puede provocar lo que se conoce como enfermedad genética, que es **hereditaria**.

Para curar las enfermedades, la comunidad internacional trabaja en el **Proyecto Genoma Humano**, que intenta determinar la secuencia de las bases químicas que forman el **ADN** e identificar todos los genes del genoma del ser humano.
Sanjeev Bhaskar

**Sanjeev Bhaskar** OBE is a British actor, comedian and television presenter who portrays Giles Baddicombe, a lawyer in Season 1 of the Prime Video series *Good Omens*.

## Biography

Bhaskar is best known for his work in the BBC Two sketch comedy series *Goodness Gracious Me* and as the star of the sitcom *The Kumars at No. 42*. He also presented and starred in a documentary series called *India with Sanjeev Bhaskar* in which he travelled to India and visited his ancestral home in today's Pakistan. Bhaskar's more dramatic acting roles include the lead role of Dr Prem Sharma in *The Indian Doctor* and a main role as DI Sunny Khan in *Unforgotten*. Bhaskar has been the Chancellor of the University of Sussex since 2009. In 2003, he was listed in The Observer as one of the 50 funniest acts in British comedy. In 2006, Bhaskar was appointed an OBE. Before the 2010 general election Bhaskar was one of 48 celebrities who signed a letter warning against Conservative Party policy towards the BBC.

## References

1. ↑ The A-Z of laughter (part one) - The Guardian
2. ↑ General Election 2010: leading stars oppose Tory BBC plans - Telegraph
¿Que es el material genético?

## Material genético

### Etiqueta

El material genético es toda la totalidad de ADN que presenta un ser vivo. Nuestro material genético está formado por moléculas de ADN. Estas moléculas están hechas de dos largas cadenas complementarias unidas y retorcidas entre sí.

**Material Genético**, es cualquier material de origen vegetal, animal o microbiano u otro que tengainformación genética y que la transmita de una generación a la siguiente. Esa información controla la reproducción, el desarrollo, el comportamiento, etc. Para todos los organismos vivos actualmente conocidos, el material genético consiste casi exclusivamente en ADN, con la excepción de algunos virus y priones (formas infecciosas de proteínas normales).

## Qué es el material genético

El material genetico es toda la totalidad de ADN que presenta un ser vivo. Se compacta en un área discreta de la célula formando los cromosomas. Éstos se encuentran en los virus, células procariotas, en el núcleo de células eucariortas y en cloroplastos y mitocondrias. Se emplea para guardar la información genética de una forma de vida orgánica. Para todos los organismos conocidos actualmente, el material genético es casi exclusivamente ácido desoxirribonucleico(ADN o DNA). Algunos virus usan ácido ribonucleico (ARN o RNA) como su material genético.

## Origen

Se cree generalmente que el primer material genético fue el ARN, inicialmente manifestado por moléculas de ARN que autoreplicaban flotando en masas de agua. Este período hipotético en la evolución de la vida celular se llama la hipótesis del mundo de ARN. Esta hipótesis está basada en la capacidad del ARN de actuar como un material genético y como un catalizador, conocido como una ribozima o ribosoma. Sin embargo, cuando las proteínas (que pueden formar enzimas) llegaron a la existencia, la molécula más estable,el ADN, se convirtió en el material genético dominante, una situación que continúa hoy. La naturaleza de la doble cadena del ADN permite que las mutaciones se corrijan, y también el ARN es intrínsecamente inestable. Las células modernas usan el ARN principalmente para construir proteínas de las instrucciones del ADN, en la forma de ARN mensajero, ARN ribosómico y ARN de transferencia. El ARN y el ADN son macromoléculas compuestas de nucleótidos, de los cuales hay cuatro en cada molécula. Tres nucleótidos componen un codón, un tipo de "palabra genética", que es como un aminoácido en una proteína. La traducción codón-aminoácido se conoce como Traducción (genética).Este material genetico es muy importante para la planta ya que gracias a esto nosotros los humanos podemos reconocerlas por fechas.

## Cómo está formado

Nuestro material genético está formado por moléculas de ADN. Estas moléculas están hechas de dos largas cadenas complementarias unidas y retorcidas entre sí. Las cadenas están formadas por bloques o subunidades. Estos componentes del ADN (polímero) son los nucleótidos (monómeros); cada nucleótido está formado por un grupo fosfato, una desoxirribosa y una base nitrogenada, y son precisamente las bases nitrogenadas las que portan la información.
Crowley's Apartment

**Crowley's apartement** is located in Mayfair, London.

## Background

Crowley lives there throughout the events of Season 1. As it is owned by Hell, he got kicked out after him and Aziraphale stopped working for Heaven and Hell.

Shax lives there in Season 2, although Crowley asks if he can have the apartment back after Shax doesn't need it anymore.

## Gallery

Good and evil wrestling with evil triumphing
## Notes and trivia

* The statue on Crowley's flat represents good and evil wrestling with evil triumphing. When Neil Gaiman saw it he asked "are you certain that they're wrestling?"