Showing posts with label estimate. Show all posts
Showing posts with label estimate. Show all posts

Monday, 15 May 2017

Agile games: estimation

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

Agile games - estimation


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

Agile estimation games


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):

Agile estimation games


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.

Thursday, 18 June 2015

Scrum issue #35 :: Any estimate is better than no estimate

“What do you think, how big is it?” or “How much time do you need to solve it?” – I will ask any of the two questions often, especially when urgent new story or task is coming into the sprint backlog during active sprint.

The story behind is: I worked with a team sometime ago and noticed a very strange pattern in their Scrum board. There were some tasks estimated ‘0h’ into their current sprint backlog, but those were not moved to the ‘done’ column. For me a task set to ‘0h’ remaining time means ‘done’ and I pointed that quickly. It turned out, those were items in progress: support requests, bugs or any other complex/unknown tasks which cannot be precisely estimated. At first I thought we could somehow breakdown those items and estimate the effort but most were already set at a level of just one task. For example if was a bugfix request the needed steps would be: to analyse/debug and then fix. And for complex systems no developer would be able to precisely estimate how much effort would be needed to debug and identify the cause of the issue. Even nowadays I usually hear a statement like ‘If we are lucky it could take less than an hour, if not – it could take weeks’… Not good.

The worst part is that those ‘0h’ tasks are hidden time sinks and could block some team members for weeks. In my observations this is one major reason why waterfall projects usually fail to deliver on time. I’ve seen developers stay blocked for months struggling with an issue that simply could have been ‘rejected’ after being identified as a huge time sink in less than a week.

So instead of estimating time to delivery we first estimate time for ‘spike’. For non-practitioners ‘spikes’ are time-boxes dedicated to just analyse, identify the complexity and estimate a certain issue. The time-box could vary but in my experience should not be bigger than 2-3 days. If there is still no progress after that, we contact the product owner and either offer another spike or think about workaround to be introduced in less time. Another alternative – the issue could be rejected or flagged as ‘not so important’, and the client just advised not to use the specific scenario in which it occurs.

After spiking, the issue could turn out to be huge and require more time than one sprint to be entirely developed/fixed. In that scenario we split it in terms of value and deliver as much as possible to the end of the particular sprint. The remaining part is up to the product owner to prioritise.

Another possible outcome is to identify the issue as being blocked by another issue. It is put on hold then and the Product owner decides what the priority is as usual.

For a complex/unknown story, the developers usually assign a lot of hours to the tasks (just to have some buffer). This is somewhat ok – but it is important to reduce the remaining hours accordingly as the level of knowledge increases. Don’t just log hours – look at the ‘time remaining’ value on a daily basis and adjust it. This way there is a much better transparency on the progress and the real risks for delivery by the end of the sprint are clearly visible.