This topic is always a problem. And main thing is not about user stories, but about achieving the common understanding of things among team members, product owner and stakeholders. That’s why it is important to find the best way how stories should look like and how to split them in case if they are too big and ambiguous.
Common story problems:
- Stories cover too much
- Stories have too much dependencies
- Stories do not clearly explain what user wants
Splitting stories lets us separate the parts that are of high value from those of low value, so we can spend our time on the valuable parts of a feature. (Occasionally, we have to go the other way as well, combining stories so they become big enough to be interesting.) There’s usually a lot of value in getting a minimal, end-to-end solution present, then filling in the rest of the solution…
While browsing an internet i found some great link about this:
Is it easy to spend 20% of time on innovation and stuff that developers really like to do? I think definitely not and the success is not guaranteed …
- When can a developer take his time?
- What restrictions are there about what can and can’t be done in that time?
- How do people manage their schedules? Should they manage it?
- Is this time should be tracked?
- How is it decided what people can work on?
- How do you stop someone’s project if it’s deemed not useful? Who deems it this? Is there a committee? Peer review?
- How do projects “graduate” from 20% time?
- How is overall success of the program judged? $$? Customer value? Engineer happiness?
- Should developers form a team, or should it be single projects?
But despite all these difficult questions probably it’s worth trying … What do you think?
Effectiveness of retrospectives is still important topic for me because i don’t always see that people come out after retro with good action plan. As I was writing previously here retrospectives are very important for agile teams. They help us to look back and find ways for improvement…
Main struggle for a Scrum Master is to make people talk. We noticed that the approach described in my previous post will not necessarily lead to a discussion with good action plan (at least in our case). People sometimes complain that they have no ideas 🙂 IMHO, it happens because we are just sometimes lazy…
That’s why Scrum Masters in our teams started to look for better/additional approaches of facilitating retrospectives.
And we found it – Happiness Histogram. We selected following topics:
- Team Performance
- Meeting yearly targets/roadmap
- Communication with other teams
- Internal communication
We use histograms in addition to previously described method. Workflow is the following:
- Team members fill in histogram with their results
- Team discusses results and tries to understand trends of overall mood in the team
- After that team continues a retrospective with previously selected approach. But they are full of ideas now 🙂
Why do I think these two approaches work better together:
- Histograms allow people to relax and express their feelings in numbers about certain topics
- Good approach to remember global goals and see how we approach them
- After good initial conversation it is easier to sit down and come up with actions for Start, Stop and Continue …
- Combining things rocks! You will never get bored…
Adoption of any agile framework is very interesting and non-deterministic process. Basically anyone can do anything based on simple rules. Rules vary from framework to framework, but it’s nothing comparing to waterfall or similar.
Freedom and flexibility of choosing how you work and what works best for you is a very nice thing, but … it can lead to a very weird decisions sometimes. Team’s decision to change basic rules like meetings sequence, time boxes, etc. should be a signal for you that something is really going wrong. Consider having a corrective actions or at least track it for some period in order to understand the real source of the problem.
I see only two reasons for such changes:
- You don’t really understand what is the goal of a certain practice and your knowledge of it is superficial
- Daily stand up is not for problem solving or big discussions, but for understanding the pulse and highlighting issues for further discussion during the day
- Retrospective is needed not for discussing the output or success of the sprint, but for discussing how the process was applied and what should be improved or changed
- You are trying to solve the consequence of the problem, but not the source of the problem
- Try “5 Whys” approach or something like that to uncover the real problem
Before you decide changing basic and trivial rules of any agile framework please make sure that you really know and understand what you do!
p.s. this post is inspired by this discussion in this group – “Scrum Alliance – transforming the world of work.“.
p.p.s. “inspect and adapt”
We all face a lot of interruptions during our everyday life, especially at work. We all know that these interruptions do not help us to be effective …
Here is one practice that will help you to handle team interruptions, especially in early stages of agile (or any process) adoption.
This entails putting a post-it on the board for each interruption, with the interruptor, the interruptee, a short description and a time cost. This forms a snake of shame after a while. You can easily use this tail to show that pretty much of sprint effort might have been redirected to support and other sinks.
So, this should be useful and easy way to show how much productivity could be lost to these “little” interrupts, and and hopefully the frequency of interrupt will reduce after all stakeholders see and understand the impact!