Agile Coach & Scrum Berater in Berlin

Alex Bieth, MBA

T - 015787011932

E - [email protected]

Erfahrung mit der Implementierung von Scrum (als Head of SEObei Spreadshirt) als Scrum Master und Product Owner

Agile Coach bei HelloFresh (Marketing Content Marketing) für 9 Monate.

Scrum Master zertifiziert (seit 2013)



Backlog creation & correction

Agile training

Sprint implementation

mit Kanban, Daily Stand-ups, Grooming, Sprint planning and Retrospective

Follow-up: Reports, Sprint Velocity


HelloFresh logo

With HelloFresh: Successfully implemented Scrum in the Marketing Business Analytics Team.

• Backlog Refinement (from over 1k items to less than 300)
• Coaching and Implementation of Scrum Events
• Coach Team for Story Points /Story writing Implementation
• Sprint Velocity progress controlling
• JIRA Optimization: projects overall & Scrum board / Kanban board (using labels)
• Automation from Service portal tickets (components, assignment, versions, etc)
• OKRs as epic "themes" and quarterly controlling

Profile image

Sabine Veidemane

Team Lead CRM Analytics - Marketing Content Marketing @ HelloFresh

Alex joined our HelloFresh Marketing BI team in October 2019 as an Agile expert to completely revamp our messy processes around using Jira for workload planning and monitoring. Over the next few months he set our team up for future success as he switched us to new workflows, Jira boards and working in 2-week Sprints. He introduced Agile ceremonies, such as Sprint planning and Retrospectives, and concepts around Story Points for ticket estimation which brought it all to life and made us much more focused and structured! As a Team Lead within Marketing BI, I can say that it also allowed me to bring my stakeholder expectation management to a whole new higher level. It was a real pleasure to work with Alex and his down-to-earth and approachable can-do attitude!

Scrum’s Three Pillars of Empiricism

Scrum is a process framework that has been used to manage work on complex products since the 1990s and is based on 3 pillars of empirical process control: transparency, inspection, and adaptation.


The important aspects of the process are visible to the people responsible for the outcome and are defined by a common standard so that observers share a common understanding.


Scrum users frequently inspect Scrum artifacts and progress to detect variances.


If one aspect of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process must be adjusted to minimize further deviation.

The 4 Scrum events for inspection and adaptation: Sprint Planning • Daily Scrum • Sprint Review • Sprint Retrospective

Scrum Events

The Sprint (up to 1 month max)

A time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

During the Sprint: • No changes are made that would endanger the Sprint Goal; • Quality goals do not decrease; and, • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change.

Sprint Planning (max 4h for 2-week sprints)

Answers two questions: • What can be done this Sprint? • How will the chosen work get done?


The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint. The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.


The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.

The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner.

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

Daily Scrum

The Daily Scrum is a 15-minute time-boxed event held every day at the same time for the Development Team.

Development Team plans work for the next 24 hours and inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work.

The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. :• What did I do yesterday that helped the Development Team meet the Sprint Goal? • What will I do today to help the Development Team meet the Sprint Goal? • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum.

This is a key inspect and adapt meeting.

Sprint Review

What: informal meeting collaboration & feedback what was done in spring, with all including PO & SH When: at the end of the Sprint Why: to inspect the Increment and adapt the Product Backlog if needed. How long: up to 2h

Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.


ensures that the event takes place and that attendees understand its purpose. teaches everyone involved to keep it within the timebox.

What is includes:

• Attendees include the Scrum Team and key stakeholders invited by the Product Owner; • The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”; • The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved; • The Development Team demonstrates the work that it has “Done” and answers questions about the Increment; • The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed); • The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning; • Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and, • Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

Sprint Retrospective (needs to be positive and productive)

Goal: to inspect itself (good and less good: people, relationships, process, tools) and plan improvements for next sprints (enjoyable & efficient), Adapt Definition of Done When: after Sprint Review How Long: up to 1.5h

Improvements for next sprints: adaptation of inspection from Team

Backlog Refinement

Who: PO and Team What: review items in PB to insure it contains prioritized appropriate items, and top of Backlog ready for delivery. When: regular basis and may be an officially scheduled meeting or an ongoing activity. The Scrum Team decides how and when refinement is done. Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion. How long: Refinement usually consumes no more than 10% of the capacity of the Development Team.

What it included: removing user stories that no longer appear relevant creating new user stories in response to newly discovered needs re-assessing the relative priority of stories assigning estimates to stories which have yet to receive one correcting estimates in light of newly discovered information splitting user stories which are high priority but too coarse grained to fit in an upcoming iteration

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

Scrum Team

Product Owner (PO)

The PO is responsible for maximizing the value of the product resulting from work of the DevTeam and is the sole responsible for managing the Product Backlog and is accountable for: • Clearly expressing Product Backlog items, ensuring the DevTeam understands items in the Product Backlog to the level needed. • Ordering the items in the Product Backlog by priority

The DevTeam

The DevTeam consists of a structured team of professionals who manage their own work are the only who deliver a potentially releasable Increment of “Done” product at the end of each Sprint. A “Done” increment is required at the Sprint Review. • No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality; • Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment and Accountability belongs to the Development Team as a whole.

The Scrum Master

The Scrum Master is responsible for promoting and supporting Scrum by helping everyone understand Scrum theory, practices, rules, and values. The Scrum Master serves the Product Owner: • Ensuring that goals, scope, and product are understood by everyone on the team • Finding techniques for effective Product Backlog management; • Helping the Scrum Team understand the need for clear and concise Product Backlog items; • Understanding product planning in an empirical environment; • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value; • Facilitating Scrum events as requested or needed. The Scrum Master serves the DevTeam • Coaching the Development Team in self-organization and cross-functionality; • Helping the Development Team to create high-value products; • Removing impediments to the Development Team’s progress; • Facilitating Scrum events as requested or needed; and, • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood

Scrum Artifacts

Product Backlog

What: Dynamic Ordered List of known items needed to be delivered. It continuously evolves (prod & environment) Resp: PO: content, priority,ordering, availability Each Items: description, order, estimate, and value. Also sometimes test descriptions that will prove its completeness when “Done.” A good user story should be: “I” ndependent (of all others) “N” egotiable (not a specific contract for features) “V” aluable “E” stimable (to a good approximation) “S” mall (so as to fit within an iteration) “T” estable (in principle, even if there isn’t a test for it yet) A good user story should be: “I” ndependent (self contained) “N” egotiable (leave space for discussion) “V” aluable (add Value) “E” stimable (to a good approximation) “S” mall (so as to fit within a sprint) “T” estable (item should have enough information to be testable)

Example of a User Story:

1. “As a client, I would like to be able to make a purchase without log-in so that I don’t waste time I do not want to invest.”

2. More Description if applicable

3. Acceptance criteria:
User is offereed the option during checkout
User still needs to enter an email address
User must still be offered to be added to newsletter

4.Estimation: 3 Story Points

Monitoring Progress Toward Goals Various projective practices upon trending have been used to forecast progress, like burndowns, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.

Sprint backlog

What: Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.It is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting. The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

Monitoring Sprint Progress At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

Increment The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it

Artifact Transparency: Definition of “Done”

When a Product Backlog item is described as “Done”, each team member must understand what “Done” means to ensure transparency. The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning. As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. New definitions, as used, may uncover work to be done in previously “Done” increments. For example, in software, a Definition of Done may be: “Done means coded to standards, reviewed, implemented with unit Test-Driven Development, tested with 100 percent test automation, integrated and documented.” In a services context, it may be like this: “Done means every task under the User Story has been completed and any work created is attached to the User Story so the Product Owner can review it and make sure it meets his or her expectations.”