Granikos Technology Blog

SCRUM as a method in Agile Project Management


In the preparation of this article, we discussed several ideas, how to introduce Scrum to you. In search of inspirations we have found the introduction video from the Scrum alliance.

In the end, this is a pretty short 80-seconds introduction to Scrum, which we would like to show to you, instead of reinventing the wheel again.



In addition to the video we would like to share more information:



Expectations to Scrum:


Scrum is very good when it comes to establishing agile methods into an organization. By providing a simple approach it can easily be picked up and enhanced. Also Scrum is very well known and there are lots of experienced Scrum Coaches in the outside world of Covestro.


Scrum is a framework which provides a basis of 3 roles, 4 activities and 3 artifacts, which will now be explained in detail.

Each Scrum implementation is different though. Depending on the project or the organization there will be additional roles or activities. Scrum focuses on communication and collaboration by discussing requirements and short feedback cycles, which is the most important thing to keep in mind.


In the following we want to explain the different roles, activities and artifacts. Furthermore we want to provide you a check list what you have to prepare for your first Scrum project.




User Stories

A simple method to describe requirements, by a user's perspective, with only one or a few sentences. Usually a user story consist of Who? What? And Why?

e.g.: "As a user I want to be able to back up my data in order to recover it in case of an error."

User stories are constantly refined and extended during the project. They are the basis for discussion about the features. This will help to get a clear understanding of the requirements.


An iteration of Scrum which is usually between 1 and 4 weeks long. Or in other words: This is the timeframe, in which work is planned continuously. Once the duration is set it should not be changed during the project though.


Artifacts provide information about the product, the requirement and the progress. The scrum team permanently works with the artifacts. For instance, an artifact is the list of requirements which are known so far.


Activities are mostly meetings which are part of each sprint. (The sprint itself can be seen as an activity too) By discussing and/or working with the artifacts during the activities, the project progress and obstacles become transparent.

Definition of Done

A project specific agreement which defines when a user story is completed.



  • Product Owner
    • Manages the product backlog and overviews all user stories
    • Drives the product vision
    • Represents the project stakeholders and gathers requirements and feedback from them
  • Scrum Master
    • Establishes the Scrum process and makes sure that the process is followed
    • "Coach" of the Dev. Team
  • Development Team
    • Self-organized and cross functional (tester, designer, architect, developer)
    • Realizes the user stories


Additional involved persons:

  • Stakeholder
    • Involved in creating the requirements
    • Give feedback about the product increment
    • Examples: User, Application Owner, Application Manager, etc.



  • Daily Scrum
    • Dev. Team + Scrum Master
    • Daily stand up meeting: What did I do yesterday? What am I doing today? Anything that hinders my work?
  • Sprint Planning
    • Product Owner + Dev. Team + Scrum Master
    • "Sprint Kickoff" - once per Sprint
    • Define Sprint scope, clarify last questions and estimate effort
    • Outcome = Sprint Backlog
  • Sprint Review
    • Product Owner + Dev. Team + Scrum Master
    • Review product increment with stakeholders and collect their feedback
    • At the end of each Sprint
  • Sprint Retrospective
    • Scrum Master + Dev. Team
    • Review the Scrum process
    • Identify optimizations for the Scrum Process and define tasks to realize the optimizations
    • At the end of each Sprint



  • Product Backlog
    • List of all requirements to the product, which are known so far
    • Prioritized and refined by the Product Owner
    • Requirements can be changed, added or removed from the backlog
    • Single source of requirements for changes to the product
  • Sprint Backlog
    • List of all requirements which are planned to be realized in the next sprint
    • Cannot be changed during the sprint
    • Managed by the Dev. Team once the sprint started
  • Product Increment
    • Result of each sprint
    • Can potentially be used by the customer


When you want to start your first Scrum project there are several tasks which should be completed upfront:


  • Define your Scrum team (Product Owner, Scrum Master, Development Team)
  • Explain Scrum to the project team and especially explain the roles
  • Identify Stakeholders and involve them into the project setup
  • Establish an agile mindset, explain reasons for Scrum and the agile approach, make sure the approach is understood and accepted
    • The initial set up is not carved in stone, it will evolve during the project together with the Scrum experience of the team mainly based on the Sprint Retrospective
  • Decide on a Sprint duration
  • Set up the meetings, reserve rooms and plan them ahead ideally for the whole project time
  • If needed design additional roles/activities but do not overcomplicate the process



This was the second part of our small Series about Agile Project Management. Look out for the next part which we are going to publish soon called "Agile Project Management – Agile Project Management in real Life"

The whole Series contains 4 pieces:

Agile Project Management – Basics (Part1)
Agile Project Management – What is SCRUM (Part2)
Agile Project Management – Agile Project Management in real Life (Part3)
Agile Project Management – Agile on the next Level – Program Management (Part4)

If you have any comments on our Articles, your Feedback is highly welcome.



Weiterlesen »

What is agile?

Today we start with our  short series about agile Project Management with this first article.

Agile Project Management

Agile Project Management - The "evil dark method" which opposes the good old Waterfall Model!

Nowadays almost everyone (at least in IT environments) talks about agile project management methods.
Some already checked them out, but often enough there are some counter positions to these methods which are related to some unclear things within the methodology.

This small series will try to describe in detail what agile project management is and what are the success factors.

First of all: agile project management is a methodology and a mindset! It is NOT a strictly designed process, which will solve problems magically.
Key points of "agile" are:


  • Individuals and interactions over processes and tools

  • Working software over comprehensive documentation

  • End User collaboration over contract negotiation

  • Responding to change over following a plan


Agile Project management works iterative, the product AND the process will be reviewed and optimized after each iteration

The highly collaborative structure focuses on teamwork and end user transparency as in showing actual project progress or problems which slowed down the progress

At the end of each iteration there will be a product increment which can be used by the customer, this creates actual value and ROI even before the end of the project

  • Individuals and interactions over processes and tools

    • Changing requirements & environment
    • Misunderstanding of requirements
    • Scope creep
    • Change of resources
    • Lack of communication between End User and IT

Agile Project management can be used in nearly all custom development projects.


However there are certain scenarios where agile might not be the to-go option:

If your project has 100% fixed requirements, which will surely not change during the project (by the way...just because they are written down, it does not mean they are fixed!)…

If you roll out "commercial off-the-shelf" software, which is already packaged and automatically distributed (think about MS Office for example)...
If your project deals with upgrading or patching a system
… then agile might not be the right approach.
If you are thinking about doing your own agile project it is highly recommended to involve an already agile-experienced colleague as an "Agile-Coach".
He can help you to set up the process and working mode and help to get a clear understanding what agile is about.
Here are some doubts which are quite common regarding agile methods:

A project manager or End User might say:

  • "Agile is chaos! The outcome and the goal of the project is not clear!"
    • The working mode is actually very structured and strict. There is a vision for each iteration and the project itself. This vision is the basis for the outcome of the iteration or project.
  • "I am unsure about what do i get when?"
    • After each iteration there will be a product increment which can potentially be used by the customer. It contains the most important functions, as they are implemented according to the prioritization.
  • "I am already doing agile projects all the time!"
    • Today's requirements to IT basically can't be served by following the waterfall model. This might be the reason you are already agile in a way. It still might be useful to include more agile working methods, to actually work agile and not "pseudo-agile".


The QM-People might say:

  • "Where is the documentation?"
    • Each project creates their own "Definition of Done", which has to be completed for each requirement. This also includes necessary documentation of what was actually done. Furthermore the current project management process is in rework. After the rework it will also include agile projects and therefore also give requirements for documentation.


The developer might say:

  • "There are too many meetings!"
    • If you don't think that the meetings benefit to your project - just don't do them. Agile is based on customizing and optimizing the process. If you realize later on that the meetings were actually useful - just do them again. It is YOUR agile way of working, not a "set-in-stone" process.
  • "I can't commit my workload for the next two weeks!"
    • If you can't commit your workload for just two weeks, then how can you commit on a project which has a duration of multiple months?
    • If you are not able to commit on your work, this might also show the organization in which areas there are resources missing.

The team lead might say:

  • "This won't fit to my area"
    • Discuss the approach with your customers or try it out if possible. If the customer and developer satisfaction is lower than usually, or the efficiency of the project was lower - stick to what works best for you.
    • By trying out we mean that you try the approach in a smaller project, to see if it makes sense for you. It is highly recommended to include an "Agile-Coach" who helps you to set up the project and to integrate agile methods into your work.


This was the first part of our small Series about Agile Project Management. Look out for the next part which we are going to publish soon called "Agile Project Management – What is SCRUM"

The whole Series contains 4 pieces:

Agile Project Management – Basics (Part1)
Agile Project Management – What is SCRUM (Part2)
Agile Project Management – Agile Project Management in real Life (Part3)
Agile Project Management – Agile on the next Level – Program Management (Part4)

If you have any comments on our Articles, your Feedback is highly welcome.



Weiterlesen »

Die Präsentation zum Thema "Über die Notwendigkeit einer (Langzeit-) Archivierungslösung" wurde aktualisiert.

Hauptpunkte der Präsentation

  • Ist die Langzeitarchivierung von E-Mail Nachrichten und Dokumenten wichtig?
  • Warum sollen/müssen Objekte archiviert werden?
  • Welche Objekte sollen/müssen archiviert werden?
  • Wie kann die Archivierung erfolgen?


Weiterlesen »

Microsoft Zertifizierung unterliegen einem steten Wandel. Die aktuelle Änderung brachte eine Anpassung der Zertifizierungen an die Partnerkompetenzen. In der Vergangenheit standen immer Produkte und Technologien im Fokus der Zertifizierungstitel für MCSE und MCSD. Zertifizierungen zum MCSA sind weiterhin auf Produkte zugeschnitten. 

Die aktuellen Zertifizierungsbereiche sind die folgenden Kompetenzen:

  • Mobility: IT Pro Cloud
  • Platform: IT Pro & Developer
  • Productivity: IT Pro
  • Data Management & Analytics: IT Pro & Developer
  • App Builder: Developer
  • Business Applications: IT Pro & Developer


Das PDF Document MICROSOFT CERTIFICATION PATH COMPETENCY AREAS bietet einen detaillierten Überblick über die einzelnen Zertifizierungsschritte zum MCSA, MCSE und MCSD.

Viel Spaß.

Weiterlesen »

Die Microsoft Ignite 2017 Konferenz ist heute zu Ende gegangen. Zu Beginn dachte man, wie immer, dass man so viel Zeit hat, um sich mit all den Neuerungen vertraut zu machen und Bekanntes zu vertiefen. Man verbringt aber nicht die ganze Zeit in Breakout-Sessions, sondern nutzt die Zeit für persönlichen Austausch mit Kollegen und Freunden.

Mein persönliches Highlight auf dieser Konferenz waren vor allem die Ankündigungen zu den 2019er Server Version von Exchange und SharePoint. Über die technologische Entscheidung zur Zusammenführung des Microsoft Teams und Skype for Business Clients kann man streiten. Aus meiner Sicht ist es die richtige Entscheidung. Die Reduzierung der Client Applikationen, mit denen ein Anwender täglich arbeiten muss, ist gut. Damit geht in vielen Unternehmen allerdings ein Kulturwechsel einher, mit dem schwer umzugehen ist. Die Einführung einer neuen Technologie ist oft einfacher als ein Wechsel der Arbeitskultur. Dieser Aufgabe müssen sich Unternehmen stellen, ganz unabhängig davon, ob Sie Microsoft Lösungen einsetzen oder Lösungen alternativer Anbieter.

Ankündigung Microsoft Ignite 2018 | 24. - 28. September 2018Im Vorfeld der Konferenz gab es viele Spekulationen darüber, ob es überhaupt noch neue Versionen der On-Premises Server-Lösungen geben wird. Es gibt sie weiterhin. Die Produktgruppen sind sich der Tatsache bewusst, dass es auch weiterhin Kunden geben wird, für die Cloud keine akzeptable Lösung ist. Ich glaube aber, dass immer mehr Kunden in der Zukunft ihren Weg zu Cloud-Lösungen finden werden. Insbesondere die Anforderungen im Rahmen der GDPR werden dazu führen, dass mehr Unternehmen zu den Cloud-Diensten von Microsoft migrieren werden. Relevante Information hierzu finden Sie im Office 365 Trust Center

Wenn Sie nicht persönlich an der Microsoft Ignite 2017 Konferenz teilnehmen konnten, so können Sie alle verfügbaren Aufnahmen und PowerPoint Folien herunterladen. Michel de Rooij hat sein PowerShell Script in der TechNet Gallery für die 2017er Konferenz angepasst. Den Link finden Sie unten.

Die Microsoft Ignite Konferenz 2018 findet ebenfalls wieder in Orlando statt. Merken Sie sich schon einmal den Termin vor.

  • 24. - 28. September 2018

Die Microsoft Ignite ist eine Konferenz mit mehr als 25.000 Teilnehmern. Im Vergleich zu den beiden Ignite Konferenzen in Chicago und Atlanta war die diesjährige Ignite besser organisiert und auch der Hotel-Shuttle Service funktinierte sehr gut. Ein Nachteil ist allerdings, dass die Wege sehr weit sind. Das Orange County Convention Center bringt weite Wege mit sich. Man trifft sich auf einer Konferenz dieser Größe nicht unbedingt zufällig. Meine Empfehlung ist, sich rechtzeitig zu verabreden und Treffpunkte zu vereinbaren.

Vielleicht sehen wir uns 2018 in Orlando. 



Weiterlesen »