I’ve had a great time giving my “Beyond the Daily Stand-up: An Intro to Scrum” talk at the Virtual Agile Shift yesterday (check out the conference: it’s going through the end of the month!).
There were great questions asked, some of which I was able to answer at the end of the talk, and some that I couldn’t answer as I ran out of time, but promised I’d post the answers to my blog. Hence this post!
Some of the questions make me want to write a full blog post for each, but in order to keep my commitment to answering them today, I’ll give the short answers now, but I’m saving the questions for future, longer posts.
Here we go!
What are your thoughts on Unified Engineering?
I had not heard of “Unified Engineering” before. When I first saw the question I thought it could be one of those things I knew about, but I just didn’t know that’s what it was called. That turned out to be the case.
A web search didn’t yield many results, but I’ve found this podcast from 2016 that had some references to it. Fortunately, there’s a transcript there and I was able to skim it to get a gist of it. If I haven’t misread it, my blog post from the day before my talk was exactly about that (The QA’Role in a Scrum Team), so those are my thoughts on it. 🙂
What should the Burndown be based on? Story Points? A count of stories? or is it based on hours assigned to tasks?
The Burndown represents the Sprint and it tracks the work to be done within the Sprint. That work is represented by the Sprint Backlog Items (the “tasks”), which are the way the team found to implement the user stories.
It’s very common for Scrum Teams to size those tasks in terms of hours, in which case, the number of hours is used when updating the Burndown chart. I’ve also worked on teams where we’ve decided to only track the number of tasks, instead.
The team decides what works best and has the autonomy to change the approach from one Sprint to the other, based on what the team believes the best approach is.
Is there a formula to calculate the velocity of the team?
It’s very common to calculate velocity based on the average of story points (if that’s how the user stories are sized) delivered by the team in the last 3 Sprints. We average it like that in order to account for fluctuations from Sprint to Sprint. For example, in one Sprint the team may deliver 60 story points, and then 50 on the next one. Why the drop? It could be because a team member was off sick for two days.
Also, as the team matures, the velocity tends to go up. Whenever the team formation changes (for example, a team member leaves and a new one joins in), the velocity tends to drop for a couple of Sprints. Averaging the last three Sprints help manage these fluctuations.
Who amongst the Scrum Team should take down notes for the feedback provided by the stakeholders during the Sprint Review (Demo)
That would normally be either the Product Owner or the Scrum Master, but I always encourage the other members of the development team to also take down notes where they see fit. They may see things that maybe neither the PO nor the SM picked up. It’s a group effort.
Where do Developers document what was coded?
Different people, teams, organizations do it in different ways. My personal favorite approach is a combination of things:
- Write good specs (aka “tests”). I believe there’s a good example at the bottom of this post. I also have a whole set of posts around testing;
- Add good comments to the Pull Request, referring back to the user story it implements. Include a link back to the user story in the tracking system used (Pivotal Tracker, Team System, Jira, etc…);
- Add a link to the Pull Request in the user story on the tracking system.
With such approach, we can learn about things both ways: we may come to the user story to find out what code changes (pull requests) were made to implement the story, or maybe looking at the code changes (pull requests) and figure out what they were made (link back to user stories).
How should the information gathered from a 1/1 conversation between Dev and Business be shared with the entire team?
It would depend on the nature and outcome of the conversation. Here are some ways that could go:
- If a new acceptance criteria has been come up, update the specs/tests;
- If a user story has been clarified, update the user story on the track system to reflect that clarification (maybe a change in the wording?);
- Bring it up at the daily scrum to share it with the team;
- If a more in-depth discussion with the team is needed, book a meeting and share the information there;
- Add comments to the user story in the tracking system;
- Drop a note into whatever messaging system the team uses (Slacks, MS-Teams, email, etc.)
- All of the above?
Pick the ones that work for the team and the business.
Are there agreed-upon roles and responsibilities for the various players? Ambiguity makes it more challenging – especially if Agile is new to the org
The Scrum Framework lists the three roles: Product Owner, Scrum Master, Developers. Within developers, it’s up to the team to define the roles. A development team may start with a hard separation between QA and coder, for example, the QA person tests the work produced by the coder.
As the team matures its collaboration skills, the coder may start helping QA, by teaching them how to write automated tests, while QA may start helping the coders by helping them understand the acceptance criteria better.
The roles and responsibilities within the team may change as per the team’s needs and how it grows in maturity over time.
If the user stories are not completed till we release to production then the burndown will not go down till release is done typically at/after the end of the sprint
This question touches on the Definition of Done (DoD). The idea is to have potentially releasable increments at the end of the Sprint. If the DoD for user stories at the end of the Sprint includes something like “feature deployed to production” and that item hasn’t been checked off, then yes, this story rolls over into the next Sprint. If the team tracks tasks by hours, then the hours associated with deploying to production rolls over to the Burndown for next Sprint.
On the other hand, “deploying to production” may be part of DoD for release. Depending on how the business does things, a release may only happen after a number of Sprints, with an aggregate of features built during those Sprints, so at that point, the release’s DoD should include the “deployed to production” check.
Wrapping up
I saw the tweet below early this morning. What a great way to start off my day!!
Claudio Lassala's Blog 