If you’re new to Agile, here are three things to keep in mind to build a productive team.
At first, I was planning to write about the top mistakes that novice Scrum/agile teams make. But then I wanted to say it in a positive way. So, I ended up writing about the top three improvements new Scrum/agile teams can make. Here it goes.
Focus on Stories, Not Tasks
Focus on stories (or features), and not tasks. Yes, team members still need to pull tasks from the board, and perform them. But don’t forget that the team’s goal is to complete stories. This means that when a team member has an option to pull a task from the board, the task should be part of the current on-going story. It would be better if team members are discouraged from starting a task that is not part of the current on-going story.
I’ve seen the following board (see below) several times in my few years of agile. Each story is grouped as a row (left to right) on the board. Notice how the team has completed several tasks, but none of the stories are done.
To put this in the positive, the team is encouraged to achieve a board that looks more like this (below). Here, team members are encouraged to stay on tasks with the on-going story (or feature) until it is done. They’re discouraged from starting tasks on another story. But this doesn’t mean that team members become idle. They’re asked to help other team members to get the story done.
This limiting of tasks is practiced in Kanban as WIP limits (as I’ve presented in my softtech.ph 2014 talk)
Start Only with Ready Stories
I find that only a few agile teams have heard of definition of ready (DoR). Most of them have heard of definition of done (DoD), but not DoR. I’ve seen teams start sprints with stories that are far from being ready.
Some organizations (or companies) provide a checklist to get stories ready (not just sort of ready). I’ve seen the checklist include items like: estimated at the right size, prioritized by business value, has “done” criteria. It’s difficult (almost impossible) to get a user story (or feature) done, if the team does not have an agreed “done” criteria. This “done” criteria (or acceptance criteria) is usually set before the story can be included in a sprint (as part of backlog refinement).
So, other than DoD, take a look at DoR. It might just help you and your team improve its productivity.
Split Stories to Fit in Sprint
Sometimes, user stories (or features) are too big to fit in a sprint (or iteration). When this happens, it would be better to split the user story, than to extend the sprint (to make it long enough for the team to complete the story).
I’ve witnessed teams extending their sprint cycles just to accommodate larger stories (or epics). And that’s probably because they have limited skills in splitting stories. Many new agile teams attempt to split stories by architectural layers: one story for the UI, another for the database, etc. This results into stories that are not valuable to a user, and become interdependent with each other.
The above points may not apply to all teams. But if it does, please let me know. I would love to hear your (or your team’s) experiences.
Here’s wishing you more success in achieving your team’s goals!
Originally posted at: Top 3 Improvements New Agile Teams Can Make