A team I am working with is in the storming stage of its development.
Finally.
It’s been some time that they have been forming, carefully learning each other, sometimes from afar. Each person was doing their own stuff, limiting their interaction to consultations. Every person to their own.
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.
When I was a kid cars didn’t have seat belts in the back seat. We used to fly to and fro all over whenever the
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.
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