We want to do this project given this budget, and we want to do it in Scrum/Agile!
If you are familiar with this sentence, you are in the right place and are welcome on the following series of blog articles trying to explain how the
Azure Boards module from
Azure DevOps can help us achieve this.
Disclaimer: These articles are very personal so feel free to disagree. I am hoping to provide a interesting feedback to help you make your own decisions.
Quick reminder: Why do I want a Sprint Planning
I consider the
Sprint Planning definitely as one of the most important ceremonial of the
Scrum, and among all the benefits it can provide, my favourites are:
As a developer, I can concentrate on being productive. We are supposed to have made sure that the US (User Stories) are crystal clear, and listed all the necessary tasks to complete the US.
As a product owner, I have more time to focuson preparing future US rather making sure than everything is well understood by the team everyday.
- The initial scope + the task estimates enable us to get a daily vision of our performance, as well as being able to give
more transparency to other people.
That’s being said, if everybody is convinced of its necessity, it does imply that it can be executed randomly. There are many pitfall, and duration is a very dangerous one.
Keeping the Sprint planning short and efficient requires preparation
- Let’s go for another full day of Sprint Planning! Cheers everyone!
Alright, meetings are time consuming.
And *spoiler alert* the
Sprint Planning is like any other meeting:
If you don’t prepare for it, it will be long and unefficient (and will probably kill any good will coming from your teammates).
I prefer having the team spending 4 days preparing for the next Sprint and be able to do a full Sprint Planning in half a day, rather than spending a whole day with the whole team, wasting (teammates number * 1 day) days + not getting a clear vision of the Sprint backlog.
I am also annoyed when a new User Story is explained and we either loose (who said waste?) a lot of time debating how to implement it, or either create a
PoC and move the completion of the US for the next Sprint.
To be more precise, if I was working on a project where
Time (often tightly coupled with
Cost) was not a problem, I would prefer these 2 solutions, but unfortunately I didn’t encouter too much of these kind of projects :)
And I could continue longer (tweet me if you want to continue), but let’s move on to the
How we can try to improve the duration and efficiency of the Sprint Planning.
My ideal User Stories
Yes I personally think that even in Agile, we need more than just a
sentence on a post it to be able to estimates correctly a functionality. (more details about this in a previous blog post: Do I still need traditional specifications when using User Stories?)
But a Sprint backlog is not a random list of business rules either, so let me share how I like them to be written:
- I prefer a concise
Title, with keywords easy to remember that the team will be able to reuse to communicate. I also like to add some [Tags] to see easily to which part this US is from.
Acceptance Criteriais where I am the strictest. I use the classical
In order toto understand who, what and why. (And I do insist on the
why ?to enable to think about the big picture and not just do because we were asked to…). If needed, we can also add some small impact business rules precisions in this field also.
- In the
DescriptionI usually want the links to the design as well as any other technical precision / direction.
- Very important, if I consider that the User Story is not ready, I add a
Commentmentionning the proper teammate as well as putting him in the
- It might be very specific to our organization, but we like to know to which skills the US is related to (Front-End Development, Back-End, Design, Project Management, etc.) in order to be able to do some optimization (e.g.: next sprint is heavily related to the
Back-Endso we need to think about what
Front-Enddev can do!)
- As an IT consulting company, we need to provide workload estimations using days (I could not find so far any project where we could sell Story Points workload :D), so I usually put it in the
Effortfield in order to keep track easily of the initial estimation and see how good or bad it was :)
How do we organize to write them?
Getting a finalized backlog, ready for the Sprint Planning is a Team effort. Here is my favourite process in order to get it ready using the minimum time possible:
- The PO (Product owner) write them, especially the
Acceptance Criteriawith Business rules, the
Descriptionwith the Design (if applicable). If the project we are working on was estimated ahead, we also set the
Effortwith the estimated workload in days.
- This is clearly time consuming. Main problem being that ideally up to 2 Sprints of User Stories should be ready in order to keep the Team active. Taking 1 or 2 days per Sprint to write them properly does not surprise me that much.
- Then some technical fellow (ideally experienced ones) read them, and check if everything is clear and ready for splitting and estimating.
- If not, he had some questions + mentions in the
Assigned tothe mentioned teammate (PO or designer for instance).
- He also add some
Tagsto know which skill will be needed.
- If everything is ok, he also create the technical
Tasksneeded to complete the User Story and add an
- Reviewing everything is also time consuming, especially if many comments exchanges are needed. 1~1.5 day per Sprint dedicated to this task looks pretty fine to me.
- If not, he had some questions + mentions in the
Note: Creating the
Tasksand estimating them in advance is highly debatable. However by experience, I observed that very often if we don’t do this, this is usually the experienced developer who ends up doing it during the Sprint Planning, making the whole team “waste” some precious time I would prefer them spending explaining what they conceived and how to implement it.
This second part is where this whole process shine according to me:
- It makes sure that the User Story is ready to be developped (as at least one developer could conceive how to do it)
- It gives time to perform quick background tasks:
- Get an answer from the customer
- Get additional designs
- Look for the best way to resolve the problems required by the User Story by asking feedback from other colleagues internally, etc.
That’s all for this first part about
Sprint Planning preparation with Azure DevOps.
I hope it could give you some new ways of conceiving how your team can work in Agile (or reassure the way you are doing it)
Next time, I will discuss about how to obtain a realistic capacity with Azure DevOps.
Feel free to show your disagreements or any other opinion in the comments or in reply to my Twitter @vivienfabing. May the code be with you!