This blog will discuss the problems we encounter when adopting scrum and the solutions we choose to solve those problems.
Scrum itself is a nice approach to agile development. It helps on short development life cycle, frequent review, continuous valuable delivery, team diversity, team self management , etc.
To achieve all of these, scrum use the “sprint” as one short software development life cycle.
When adopting scrum, we encounter these problems:
Problem 1:
Items cannot match with remaining resources even after break down.
Because some items are too big for the remaining time of team after estimation of chosen items. To solve that problem, we tried to split the items with different patterns, such as workflow steps, major effect, simple first then complex, etc.. In short, we split user stories into smallest user stories yet these stories still are valuable to our clients. This actually works quite well at first. But after a period of practicing, we realized that no matter how we break down the items, we will sometimes encounter the same problems again because of the limitation of resources (roughly team members time * sprint length ).
Problem 2:
We think it is a waste for discussing items in PBR but not taken in this sprint. The reason is that after 1 or 2 sprints, most of us could not remember what is discussed and we need some time to refresh our memory or worse, we have to discuss again.
Luckily we are introduced another concept “KanBan”, which is another approach to agile development. After some discussion, our team decided to try to combine “KanBan” and “Scrum”.
Solution for us:
Our current workflow has rules like this:
1. We only focus on one item with highest priority in one sprint.
2. We have PBR, Sprint planing part 1 part 2 in one shot(still one by one but continuously).
3. Right after that, we get into the normal development cycle like the normal scrum sprint.
4. Whenever we finish this item(DOD), this sprint ends and we go on to next item.
5. The retrospective is scheduled to every week, and is flexible depends on members’ availability.
By doing this,
1. We still have the benefits of scrum like short SDLC, quick feedback, continuous improvement, etc..
2. We save the time of discussing same item more than once in different sprint PBR
3. We don’t need to waste time to figure out which item could fit in one sprint.
Hope the solution is helpful for teams having similar problems when adopting scrum.
T.8ytes by Titansoft 