the points that catched most of my attention was the rule of working on one backlog item at a time (of course you need to be reasonable here, as there might be situations where it is necessary or better to parallelize, but as a general statement you should avoid that).
another point that confused me was the sizing of the backlog, we previously sized the items in days, but we got convinced that sizing should not be dependent on time as you want to estimate how big your item is and not how fast you can solve it.
one interesting practice to sizing is the poker play: where you use cards with the values of an almost fibonacci sequence to "size" your backlog items among your team.
a very important point is to define beforehand the acceptance criteria with the Product Owner and also check what went well and what could be improved by the end of each sprint.
according to the curse, for having scrum running efectively you need to have:
- Timebox
- Self organization
- Full principled
- Potential shippable code
and for documentation, it is basically the product backlog (PB) & the sprint backlog. \o/
as an interesting side note, the word backlog refers to the containers that are transported by ship and this backlog is also ordered by importance: the most important containers are placed in the bottom in case there is any storm.
the things we are going to improve in our team for the next sprint: do the daily scrum meetings DAILY, time boxed and on time, work on the same backlog item until it is really done before moving to the next one and doing the sprint planing 1, . planning 2, review & retrospective in order to improve after each sprint. In order words, just apply Scrum more strictly :)
the main benefit of the training was to understand the principles of the Scrum methodology. With that in mind you should be able to adapt it to your day to day work, without loosing the agile principles.
