Agile & Scrum foundations (business edition)

(image by EPAM Bulgaria)

“It was very useful, and I had quite a lot of fun… please keep it this way”, I was told after we completed the Agile & Scrum foundations training for business and administration edition. And I felt happy… really happy for delivering the training in a way I believe every training or talk should be delivered. To tell the full story - it is one of the few things I remembered clearly from WEBIT ’11, until today. The mantra was constantly repeated by Marvin Liao (Yahoo) “useful + fun = valuable”, and it became something I truly believe in.

It was challenging, but also interesting to adapt the training for the business team so they, not only understand what Agile and Scrum in software development is, but also get something useful to implement in their work and even everyday life.

So, they got a game to create product backlog, and learn how to write user stories and acceptance criteria. Followed by prioritizing, estimating and committing to items from their backlogs for the week (sprint).

We taught them simple relative estimation (by sizes) techniques, but also the folks experienced the ‘entire joy’ of playing planning poker and how difficult it could be to agree on a simple ‘5’ :).

In the middle of the training we did (my personal favorite) sprint simulator game where the experience included some random / real-life events, which could happen during the sprint and the teams had to adjust and adapt to.

And we ended up with review on the last day of the training, where the teams had to present if they managed to complete their sprint goal and demo the results of the completed user stories, followed up by retrospective session to inspect and adapt. As a trade-off the topic of XP and some of Kanban was kicked-out, but all for good.

It was so much fun, and the vibe and energy were amazing. It’s really cool to train folks not involved in software development in Agile & Scrum.

--

Here is some of the feedback, as usual:

‘The idea of involving non-tech people in such a training was pretty cool in general. I liked a lot the way, the additional sessions were presented. It was very useful not only to learn the general information about Agile/Scrum but also to see it in practical exercises and examples’

‘I liked the most the part with creating our own backlog (product) where everyone should focus on defining epic, user stories and AC / tasks for them. It helped a lot to have better idea of additional tasks and how to prioritize in a good way’

‘The training gave me the opportunity to understand that flexibility is important, as well as change, during project management’

‘It should have been a little bit longer – there are many other useful practices, which we could learn. I am waiting eagerly for e second edition of the training’

--

And yeah, it was privilege and real joy to train such enthusiastic and energetic group of people.

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.