All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. For privacy concerns, we cannot allow you to post email addresses. Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. Nonetheless, when I said something like "give credit to the team", I also wanted to say that the concepts of "efficiency/effectiveness" within the organization should be reconsidered (as part of the "ongoing Agile transformation") from output focused to outcome focused.īy posting on our forums you are agreeing to our Terms of Use. I know the number of tickets and story points completed are not "that important" in Scrum. Why I think it is useful to have a ticket for most of tasks performed? Personally, I think that having a fairly medium-level "detailed" (not low-level) board/Sprint Backlog enables having historical data-driven discussions within the team: for instance, the "number of tasks added during the Sprint" - most of the time, these tasks were not known/planned at Sprint Planning - may give a hint about "why we did not achieve our Sprint Goal this Sprint?" as well as give a slightly better overview and "credit" about the number of tickets "and Story Points" completed in order to help planning next Sprints. The organization does not firmly impose having one ticket for each task. transparency, board/flow management, even if that is more a Kanban concept) - which implies I could more tend to give instructions/suggestions (sometimes even "bad ones") or other perspectives when I think they can be useful, for example in terms of mindset - unfortunately, despite myself, that might lead to some sort of micro-optimizations/micro-management. "As long as the techniques are working for the Developers and they are able to inspect progress, make adaptations to get closer to achieving their Sprint Goal, and make the work transparent, how they run their Daily Scrum or manage their Sprint Backlog is of no concern to me unless they ask for feedback or suggestions.": As a Scrum master (and sometimes Developer) in this team, perhaps I assume the "teaching" stance more than I should, - above all for some "basics"/pillar topics (e.g. Let me give a bit more context and my thought around this topic. However, it may not necessarily be important for anyone else to know about X and Y and even getting into that level of detail is too much for planning the day at the Daily Scrum.įirst of all, thank you everyone for your precious comments! I agree with you when you say the most important discussion at the Daily Scrum is about how we can collaborate together towards the Sprint Goal, and that Sprint Retrospective is one of the occasion to discuss topics similar to this one.
If knowing that progress was made on X and Y is important to someone else, then perhaps X and Y should be on the Sprint Backlog. It very well could be that X and Y are parts of something else on the Sprint Backlog, but not explicitly visible by themselves. I'd also ask the team to look at the granularity of the items in their Sprint Backlog and see if it makes sense, to them and to promote visibility to key stakeholders.
What the team is going to do today to get closer to the Sprint Goal is far more important than what the team did yesterday. Part of my advice would mirror Ian's - the purpose of the Daily Scrum is to plan. If a Developer on the team did ask me for feedback in this situation, I'd have a couple of pieces of advice.
As long as the techniques are working for the Developers and they are able to inspect progress, make adaptations to get closer to achieving their Sprint Goal, and make the work transparent, how they run their Daily Scrum or manage their Sprint Backlog is of no concern to me unless they ask for feedback or suggestions. No one can mandate the Developers to use specific techniques for conducting the Daily Scrum and managing the Sprint Backlog, but there may be opportunities for the Developers to receive feedback on their efforts to make the work visible and transparent - one such opportunity is the Sprint Retrospective. The Developers are fully responsible for the Sprint Backlog and however it's made transparent among themselves and to stakeholders.
0 kommentar(er)
