When we build the team’s board for the first time there’s many times the question of how to represent work in progress, how to show what’s going on between “Ready/Committed” (The backlog of the sprint, items ready to be developed) and “Done”.
There are usually two main options.
Bringing values down to earth
Values and principles can often seem lofty and intangible so many agile practitioners prefer to focus on tools and practices. That’s understandable but unfortunate. Because values and principles have the potential to provide us with clarity and guidance that transcends what practices and frameworks can achieve. Ideally – part of your empiric inspection and adaptation process should explore whether you are living according to your values/principles. To achieve that you can try a value-based retrospective.
We are relentlessly expanding our tools set
We at AgileSparks help companies create effective, efficient and
When we talk about the benefits of working with small batches we talk about risk reduction, about improving flow, and getting quick feedback.
I call these reasons “scientific”.
I believe that the main reason for working in small batches is getting things done. The value of getting things done is mainly a moralistic one. It is good to get things done – it does good to your soul.
This leads us to the dark side of working in small batches – The Addiction.
The Kanban method is built around improving the flow of product development. It works very well when you work according to priority. It also works well when some items have schedule constraints. When many items have schedule constraints this becomes an issue.
The Motive
I was having a discussion with one of my clients and they raised the issue that what was going on wasn’t clear. Immediately I thought of setting up a Kanban board. However, when we started to do that it became clear that the main issue is how to commit to clients about deliveries.
I’d like to share with you some tips and tricks of setting a scrum board I usually share with my clients. The bottom line is that too many tools have too many features that support old ways of thinking. Let’s look at the various items one by one
A common phenomenon happening in organizations implementing scrum is that something is missing – the big picture. People are saying “We used to have High-Level Designs – where are they?”, “We used to have an architecture before developing – where is it?”. The answer will usually be that as we are working with small batches we need to focus on what’s immediately coming up and so other things are getting neglected.
But this is a confusion. Nothing should be neglected. For sure we cannot neglect long-term thinking and planning.
Lately I had the opportunity and pleasure to facilitate a process of designing cross-functional feature teams in a self-selection process. Self-selection is a facilitated way to let people choose which team to work in. It is surprising how rare this practice is sometimes even considered eccentric while practically it is a simple and fast and produces such great results – well-formed teams with more involved and engaged people.
Why teams self-selection?
It’s a fast engaging process that creates the best conditions for a team to reach high performance.
It’s based on the assumption that with the appropriate context, people will choose to work in a team that they feel will make them be most productive, taking into account the personal relationships with the other team members, the complementary skills they bring and their aspirations for personal and professional development.
Earlier this month I was helping a software organization in an Israeli defense organization (that’s why there are no pictures) run their first PI Planning event. The day after I told my colleagues at Agilesparks that this is one event I will try to remember whenever I get into difficult times doing coaching, something that happens from time to time, coaching being what it is. I will try to remember that day because of the magic that happened somewhere around noon. And I want to tell you all about it.
Which Estimation Units Should Your Teams Use For Work Items?
Why estimate in the first place?
At the feature level, you want estimates so you can figure ROI (Return On Investment), so the business and product owners can prioritize one feature against another
At the roadmap & backlog level, most organizations want to be able to forecast, be it at the feature level or release level, so you need to be able to understand what is your organization’s capacity, and translate it into plans with dates and deliverables, milestones etc.
At the finer-grained, work-item level (typically User Story), you want to help teams understand their capacity so they can take on the right amount. In particular in teams that use a frequent planning cadence, such as that prescribed by Scrum
Still at the team level, team members setting expectations on the amount of work they plan to complete can surprise themselves, learn, and improve.
At the team level, you want to understand whether a work item is small enough, might want teams to discuss estimates as part of creating a common understanding about work and align their views
Request for additional information and prices