Agile & Scrum foundations training

Last week we completed another Agile & Scrum foundations training @EPAM Bulgaria. It’s been very intense and at the same time quite pleasant to train the wonderful group of young and hungry (for knowledge) developers at the company. 

Agile and Scrum foundations is training I have been conducting for years. The goal is to fully prepare any team or team members to start doing efficient Scrum and adopt the Agile values and mindset. It covers the following topics:

Agile mindset & values

Introducing Agile thinking and mindset is the most important topic. The idea is not only to help people understand the Agile way of thinking and doing, but also to test if it fits the personality of each participant.

Basics of Scrum, benefits of Scrum and the Scrum team

We talk about Scrum from a high-level point of view, discuss why we use the framework, and what the roles in the Scrum team are. It is followed by a game of Scrum roles. 

User stories & backlog refinement
How to write good user stories and how to initially refine the backlog is covered in the session.

Agile metrics and planning poker

I teach the secrets of relative estimation and we play a game of planning poker.

Scrum events, Scrum artifacts & tools, Kanban

We dig deeper into the Scrum events, artifacts and tools, discuss the basics of Kanban and how it could help the team.

Sprint simulator

A turn-based game, simulating a sprint for the participants to experience it in fast-forward environment.

There are also sessions about XP, retrospective game, and Agile & Scrum test so everybody could check what they learned and how to implement it in their work.

--

Some of the participants feedback:

What was good?

- Short sessions. Well-structured and filtered info – no waste, only value. Recap sessions with questions. Real life examples.

- Games and the practical tasks.

- It was fun, engaging and had real life examples. The games were very practical-oriented.

- Presentations delivery was interesting, not in a boring way.

- The emphasis was on games, practical tasks and teamwork to strengthen the experience.

What could be improved?

- Include more real-life examples.

- Even more games :)

- Make it longer.

Most useful?

- Games :)

- XP and Kanban knowledge.

- Practicing the Scrum events.

--

In conclusion, it was intense… but it was quite a lot of fun too. What is planned next is to deliver the Agile & Scrum foundations training for business and administration to support them in their day-to-day activities. Stay tuned :)

Agile games: estimation

Recently in Bulgarian Agile Community meetup we discussed some games and techniques used in Agile, related to estimating. In this post you will find three of them, related to estimation:

I. Estimation buckets
It is a way to do estimation of large numbers of items with a group of people quickly (a good alternative of Planning Poker). It also provides a way to establish initial ‘reference value’ to story points when new teams need to.

1. The product backlog items have to be written on cards. It is preferable if the team members are familiar with the items. A table or wall is setup with columns as per the example

If you do not have a reference for story points just leave the numbers blank and add them in the end.

2. Pick a random item, read it and put it in the middle bucket (under ‘8’). It is to be used as a reference.

3. Pick another item, read it, discuss it with the group, estimate it relatively to the first item and put it left (smaller) or right of it (bigger).

4. Choose another item, read, discuss, estimate relatively and place it in the appropriate bucket.

Note: If it is clear that the items scale towards only one of the sides adjust them accordingly. If the first item is smaller – scale all the items towards left (‘1’), or if bigger – scale towards right (‘100’).

5. Continue until most of the buckets have at least one reference item, and the team members get used to the relative estimation feeling and doing.

6. If there are still too many PBIs, divide them across the team members and let everyone silently (without any discussions) place accordingly.

7. Everyone in the group reviews all the items and if there is a need for correction, items are taken out, discussed with the group and placed back accordingly.

8. Write the corresponding number to each card to record the estimates.

The final result would be something like

II. Estimation game (sort of)

This we do together with some of the agile teams in Continental AG. The purpose is to foresee how many and which items will go to the next sprint backlog. It is useful when there not all team members have the expertise to do each PBI. The sprint is set to three weeks’ timeframe.

1. The PBIs are written on cards or tracked in JIRA and the team members are familiar with them.

2. We take the top ten PBIs and put them into four main categories: small; medium; large; huge.
Small – item could be finished up to a week.
Medium – item could be finished up to two weeks.
Large – item could be finished up to three weeks.
Huge – item is estimated to need more than three weeks for completion.

3. Items marked ‘small-large’ fit into one sprint. Items marked ‘huge’ need to be broken down / renegotiated.

4. Then we do some ‘typical resourcing’ as not each team member have the expertise to work on each of the PBIs. For example John and George will work on item one. Steve is the only one able to complete item two. Nick takes item three, etc… The resourcing is done according the prioritization in the product backlog so it is clear which stories could go into the next sprint.

5. Sometimes it’s not possible to take all highest priority items and the product owner is triggered to choose between 'competing items'.

6. In the end the team comes with a proposal how many PBIs and which ones could fit into the next sprint, as per the example (the green dots):

7. The product owner agrees or renegotiates the items, together with the team.


III. Project box experiment
The purpose of the ‘project box’ is to define requirements for an MVP. It could be used when a large number of stakeholders (e.g. in different departments) need to provide requirements and priorities for a product.

1. Provide each department/stakeholder group with equal amount of ‘fake currency’ or vote points.

2. Let each group define and visualize their idea in a form of a product with characteristics.

3. Individuals from each group to present to all the other groups the vision of the product (MVP) in just 3 minutes.

4. The other groups have to spend their ‘money’ or vote points on each presented MVP.

5. The most ‘expensive / voted’ MVP wins and is a candidate for production or further discussion / refinement.

---

Hope those are useful to you, guys; as usual please leave your feedback in the comments.