Moses Of Egypt

Shield your Agile team

Thu, 3 Aug 2017 19:10:00 +0000

Many things can cause distraction and shift focus. And they accumulate and become habits. You and your team will eventually get used to it and play along as you let it go one by one.

Bad news here is that it will affect your team. Whether it is on a long run or short run it doesn't matter. Better to close the door for such distractions and not let it through. This is the responsibility of the whole team. It doesn't matter if it is Scrum, Kanban or XP. The whole team should Shield themselves from such external distractions.

Examples: None delivery team attending team standup

Stand-up isn't a progress reporting event. This is a delivery team event to share what they have done and what they are planning to tackle next. What's blocking them and maybe take few things offline to action them after standup. All in a quick and lean way.

Jumping into this event and start asking questions like "Are we going to meet our goal and finish all the stories before the end of the iteration?!" or digging into too much details are signs of disrupted standup.

Usually this happen from individuals who are not part of the delivery team. Like project managers. Or maybe product owners.

The team need to stand firm and asks everyone one not participating in the delivery of the iteration/cycle to not attend the this event. You may think if they stand in the background as listeners it would be ok. I highly recommend that you don't do so. Listeners will feel the urge to comment as they are listening. Close the door completely.

Agile planning and estimation: Personal experience in estimation techniques

Fri, 28 Oct 2016 20:20:00 +0000

I worked with many agile teams on different projects. Most of them were running Scrum.  The way different teams are running planning and estimation is different from team to team. Planning meetings were also different between teams. In some teams we did max of 3 to 4 hours for 2 weeks’ sprint. Another team we used to do a full day (8 hours) for 2-weeks sprint. Most of the time it was 2-weeks sprint. Except maybe once or twice where it was 1-month sprint. And we changed that to 2 sprints eventually. 

Here are some examples of how the teams I worked with were running planning and estimation:

Estimating whole story in hours using normal playing cards. Min: 1 hr. Max: 10 hrs. If a story exceeds 10 hrs. it a sign that it is too big and we start to split it into smaller user stories and estimate each one of them. We used references/history when possible to compare user stories for better estimation.  
Our velocity was calculated in hours i.e. 80 hrs. per sprint. 
If a user story not finished during sprint. We calculate how long did it take during the sprint to be added to the velocity. Then re-estimate the remaining work in next sprint planning.
Pre-estimated user stories in T-shirt sizing or points (by PO/BA and Scrum Master). Then we create tasks on each user story. Estimate tasks in hours. Min: 1 hr. Max 8 hrs. 
Again velocity was calculated in hours. 
Estimating story with points. Then create tasks and estimate them in hours (this is the one that usually take full day planning meeting). Applying min/max values for stories and tasks. 
Velocity was confusing a bit. Because you have 2 measures now (points vs hours). And they rarely match. for example, you may find yourself achieving 20 to 25 points per sprint for 3 sprints. And when looking at hours you may discover you made 60 to 80 hours. Points here were better indicator. 
Estimating story with points. Using planning poker cards (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100). We also set max points per story i.e. 8 points. If we agreed a story exceeds 8 we try to break it into smaller ones. And estimate them.  
Velocity is calculated in story points per sprint.

There are many more techniques I've seen. I didn't participate in all of them though.

Whether you agree with the examples above or disagree. There is a team somewhere around the universe maybe doing one those techniques or running planning in totally different way.

 While technique D had a great success hit. Others also succeeded to some extent. They were not as efficient. And they were also totally bad at times. But I can't say it was a completely disastrous failure.

I totally dislike B from the above. But I am happy I tried it. Technique C made me understand that hours and points don't mix. Some use points in C to estimate user story level and use it for velocity and reference. And then create sub tasks and estimate hours on them on the fly just for micro level tracking.

I don’t think there is a fixed one way of running planning and doing estimation. You’ll find recommendations of what different people think. It will evolve with you. And later you and your team will feel comfortable with few techniques.

Agile planning and estimation: A view on Story Points

Sun, 23 Oct 2016 00:34:00 +0000

Story points are like breathing underwater when scuba diving. We aren't used to it. It takes training and practice to manage to breathe efficiently while scuba diving. We are used to breath fresh air oxygen. It is our nature. It is how we live. We do it every second. Going underwater is a bit different. It is not as easy. Yet you still breath O2 either ways.

Hours and story points are about time. We use them to estimate how long it will take to complete a user story. It is more natural for us to use hours. However, in agile planning and estimation. Story points could really prove to be more efficient and accurate.
Similar to scuba diving -breathing underwater-. Story points is new to us. It needs training & practice. It will improve over time and will become a natural thing to work with.

Example

Have a look at the following example:
Group of friends are discussing how long it will take one of them to do a road trip between 3 cities. City A to B and then C. High way distance between 2 cities A & B is 100km (~62miles). The Distance between B and C is 200km (~124miles)

One said it will take an hour. Another said it will take 2 hours. 3rd person suggested it will take 2.5 hours because of the traffic. Another adjusted that to 3 hours because of some road works. They decided to put a side few parameters that will affect the estimation i.e type of car, traffic and road works etc...

Then they agreed that it should take 2 trip points to reach city B from A. They also agreed not to map those 2 points to hours. Now they started to think of what could affect their estimation (potential risks).
In this case it could be traffic and road works on the high way.

So they agreed to adjusted their estimation to be 3 points. Using a super car could defiantly reduce time. But they agreed to stick with 3 points using a super care or normal one.

After arriving to city B. They gathered some information about the next leg of the road trip. They know it is twice the distance. Probably maintaining similar risks but with less traffic.
Taking first leg as a reference. They decided that the trip should take as twice as the first one. In this case 6 trip points.

Conclusion

After completing the trip in 3 days. They agreed that the velocity to finish a one-way road trip between 3 cities of total distance 300km is 6 trip points.

What's Next?

Plan next road trip. Which could have more legs. Or require stops and services. The team gather for planning and estimation. Having a starting velocity of 6 points per 3 days trip.

References

It’s Effort, Not Complexity

Story Points Are Still About Effort

Don’t Equate Story Points to Hours

Simplified Scrum view

Fri, 21 Oct 2016 04:17:00 +0000

Imagine Scrum as road trip. Where development team is the car & driver. Fuel is the product backlog. Fuel distributor is the product owner. Scrum Master is your specialized mechanic.

The car has a dashboard with meters and indicators. They show if everything is working as expected or there are things need closer inspection. This dashboard is Scrum transparency.

Worth to mention that this transparency is not only about development team. Fuel quality affects the engine! So if engine check light is on. It could be related to fuel -product backlog-. During road trip, continues inspection of everything affecting the car operation is important. Transparency will definitely help in proper inspect and adapt process.

The mechanic -Scrum Master- services the car. It's important to recognise that this mechanic shouldn't be fixing the car. By fixing I mean damage fixing. Because this car is self-managed. It can fix itself through continues inspect and adapt. The moment mechanic starts fix a damage i.e. engine damage. That's a sign of a serious issue. It could cause this car to be dumped.

The mechanic makes sure nothing is blocking the car from functioning properly. That include transparency. The mechanic does the normal service which helps the car to perform as expected.

This car is well made. But If you use inappropriate fuel. Let's say diesel instead of premium unleaded. This will harm its engine. If you ignored oil service. This will harm its engine. If it lacks transparency this will put the car at risk of not showing how it's performing.

This is my simplified view about Scrum. So be sure to make the most of your trip.