Scrum and XP from the Trenches review
One of our members suggested we read the great hands-on practical scrum guide written by Henrik Kniberg titled "Scrum and XP from the Trenches". It's a free eBook, and can be found at http://www.crisp.se/ScrumAndXpFromTheTrenches.html
Here is what we thought of the book in the context of easyBacklog and the features it provides to help implementing an Agile methodology with your teams. Please note, many sections within the eBook are left out in the review below, we have cherry picked the sections we felt relevant to easyBacklog and backlog management.
The book does not theorise about how Scrum and Agile can be implemented in teams, it's very much a hands-on guide describing Henrik's experience implementing these methodologies at the company Crisp where he works. As such, it's important to bear in mind that whilst his experience is extremely valuable and we can all learn from, his experience very much pertains to his environment, his team, and his own preferences. Saying that, we found his preferred way of implementing Agile and Scrum very sensible, and mostly in line with how we have been implementing Agile with theeasyBacklog beta testers.
Section: How we do product backlogs
There really isn't much to say about product backlogs as they are pretty straightforward. Henrik does cover how to deal with producte owners who create stories that don't solve a business problem, but instead describe functionality such as "Add index to table".
It's interesting to see that Henrik deviates from the recommended format for a story of "As a", "I want to", "So I can" prefixes. We can see the relative pros and cons of more flexibility versus sticking to a tried and tested format, however we have opted to stick to the "As a <role>, I want <goal/desire> so that <benefit>" format as it ensures consistency for each story and everyone can look at a story and understand the scope and business reasons for each story.
Henrik advocates the use of a shared spreadsheet over existing agile tools primarily because of speed i.e. simply entering values into a cell is faster than other agile software tools available. easyBacklog has focussed on addressing that exact issue, speed and flexibility. As such, we've now replaced all of our spreadsheets by using easyBacklog instead as it is now faster. We differ from other agile tools in that all fields are editable in a spreadsheet like view, and all editing is available through keyboard access i.e. using Tab/Shift-Tab to move forwards and backwards between fields, stories or themes. We find the tool so fast that Scrum Master / Project Managers typically goto meetings with the product owner to draft an initial estimate directly within easyBackl
Note: Currently we don't support the importance field, but do allow color coding of stories so you can "code" the importance easily using your own coloring system. We'd like to hear from people whether the importance field is something you need? If so, we'd certainly consider adding it as a core feature or possibly an option for backlogs.
View an example screenshot of the backlog interface >>
Sections: Sprint Planning
Henrik is very clear that real world interactions and physical boards and cards is preferable over software tools. When it comes to sprint planning, he advocates product owners being involved, and using physical story cards that are shifted around by everyone involved, thus ensuring everyone feels like they are participating. He talks about their experience of trying to use a projector and a backlog management tool controlled by a single person, and his experience indicates that this does not work because it's really restrictive and that single person becomes a bottleneck very quickly. And finally he talks about the justifying why a product owner needs to be involved in the sprint planning meetings because only he/she is in a position to confirm scope, requirements and importance of each story, something that is often lost on a story card by itself.
easyBacklog is very much compatible with the methodologies that Henrik outlines for sprint planning. Story cards can be printed out prior to the planning meeting quickly, and all the stories can be assigned to a sprint easily from within easyBacklog once the team has agreed what will be completed in the next sprint. It is important to remember that whilst some of our users have been providing the Agile teams with access to easyBacklog, easyBacklog is a tool designed for product owners, project managers and scrum masters. Thus, during sprint planning, we don't expect anyone in the Agile team to be using the tool, we'd expect them to be looking at the physical cards, adding tasks, estimating and focussing on the board. The Scrum Master on the other hand would possibly be updating the status of the sprint from within easyBacklog, or possibly retrospectively udpate the sprint once the planning session is completed.
An interesting idea that Henrik suggests is that each Sprint should have a goal that is communicable to the team and stakeholders. We currently don't support this concept, and do not think it is necessary as this tool is not meant for the broader team to use. These goals would be written up on the board and distributed to the team. Saying that, we'd be open to hear from our users as to whether a Sprint wiki or something similar would be beneficial to you and your team?
During sprint planning, it seems that it is quite common for teams to split larger stories into smaller ones. We currently don't support splitting stories (this can be done with Duplicate, but this is not quite the same). We'd love to hear from our users if this is something that would be of interest to you, or if this is really an edge case bit of functionality?
Henrik also talks about man days and focus factor; focus factor being a percentage representing the efficiency of the team in terms of what it can deliver. He indicates that typically his teams would have a focus factor of 70% meaning for every 10 man days, they would on average complete 7 days of work. The focus factor is effected by people being sick, impediments, efficiency of the team, and distractrions such as bug fixing or support. With easyBacklog, we tackle focus factor in a different way. Because we use story points as an estimation of complexity for a story, these points may or may not correlate with man days depending on how your teams estimate stories. However, what this represents in terms of time is really irrelevant, all you need to know is how many points a team typically produces each sprint, and divide that by the number of days in a sprint. So for example, we have a team of 2 developers producing 100 points of work every 10 working days, this would mean that their average daily velocity is 5 points per day (100 points / 10 days / 2 developers). Each team will have a good idea of what they're achieving, and this estimate of points achievable per day per team member will help you with estimating total project cost / duration based on the points in the estimate.
Henrik advocates that developers / agile team members break down stories into tasks. As easyBacklog is aimed at Scrum Masters / Product Owners, we intentionally don't offer this functionality. Tasks are typically defined in the sprint planning process and are used by the team to agree on the scope of a story, and what is involved at a more granular level. This information does not need to be added back into your backlog, all that is important are the number of points required to deliver that story from a backlog management perspective. Those tasks need to live on the task board, be visible and then be used to monitor the progress of a team to deliver a story.
Sub-section: Bug tracking vs product backlog
Finding a solution for this has always been perplexing for us because there are so many ways to address this problem. It appears that Henrik too has not yet found a single way of approaching this and suggests four approaches:
JIRA is kept separate from the backlog management, but at sprint planning meetings these bugs are presented on the board and can be included in the next sprint as new stories.
Product owner creates stories for each bug directly in the backlog
Bug fixing is not considered part of the sprint, thus this is factored in to the velocity calculations i.e. we have found a team member typically delivers 4 points of functionality a day whilst at the same time spending around 1 hour per day on bug fixing.
Have a single backlog / bug tracking system that treats everything as equal importance.
Henrik says that option 1 is his preferred choice, but he does find each team has their own style. With easyBacklog, because we are focussed on providing a tool that helps with "fixed cost agile" projects, we feel that keeping bugs in a separate system is the right way, although we'd be open to talking to our customers about integrating a bug tracking system directly into easyBacklog should their be sufficient demand. Either way, we are not convinced that bugs should be seen as stories, they have wholly different demands, and are often disruptive in that they need to be dealt with quickly especially if they are holding up a deployment or worse impacting users in a production environment. Therefore, as and when bugs arrive, the team may or may not deal with them there and then, and these are not counted towards the sprint calculations because arguably these bugs are not stories in their own right, but part of another story that was marked as complete, but is effectively no longer complete because it has a fault.
Section: Sprint communication
Henrik encourages transparency with the team by ensuring each sprint is documented and visible to the team. His comany typically set up a sprint info page in a Wiki, but it is equally valuable to simply write this information up on the sprint board and communicate to the team in the same way stories and sprint status is communicated. easyBacklog does not currently have a Sprint information page, or a Wiki for entering this type of information. We'd love to hear from our users whether this is something they would be interested in or not.
Section: How we do sprint backlogs
As mentioned above, Henrik talks about trying various systems for managing sprint backlogs, but in the end prefers physical boards where it is filled with story cards and post it notes, along with a manually plotted burn down chart for the sprint. easyBacklog too believes that this is the right approach and as such we help with the printing of story cards, but leave the sprint planning and execution to be handled with physical objects and by the team. A few of our users have mentioned that whilst this is the ideal way of working, unfortunately sometimes they have geographically separated teams and would thus like an online taskboard as well as a physical board. Our concern with this is that unless someone updates the online board when the physical one gets updated, the online version will soon be out of date. We'd love to hear from our users about how they like to approach this, and what they feel would work for them?
Henrik did mention that some companies are a little wary at first of using an entirely physical system for sprint management beacuse of traceability. However, he does point out that once a sprint is completed, there is almost never a need to look back at the sprint and decompose each task and how it progressed through the system. All that is important is how many points were completed in that story versus what was expected.
Sections: Seating and Product Owner access
Unsurprisingly, Henrik feels it is important that team members are physically seated right next to each other so that they can communicate as and when any points for discussion arrive. Simply having a few desks of separation means that it is that much harder or less likely a person will get up and talk to someone else about any issues or thoughts they have as they are working through their tasks.
For those of us working in agencies providing services to our clients in an agile way, it is important that we consider the role of Product Owner and how they can be accessible. A product owner is not necessarily they client, but could instead be someone within the agency who understands the objectives of the client, and has the mandate to make decisions on their behalf. Either way, it's really important that you consider who will be playing an active role as Product Owner throughout your project, and ensure they are accessible by the team so that any questions in regards to a story can be answered immediately.
Section: Slack time between sprints
Henrik makes the keen observation that the term sprint should be considered in that it's meant to indicate the team puts a lot of effort in to deliver something quickly and efficiently. However, it's unlikely a team can maintain a sprint forever so do need time between sprints or during sprints to slow down and recover. With easyBacklog, this slack time can be addressed in two ways:
Each sprint start date can be altered, so you could allow 1+ days between sprints for recovery if you want.
You could simply drop the average velocity to account for intentional slack time.
Section: Release planning and fixed price contracts
For us, this was the first part of the book where we felt the strategy to deal with fixed price contracts was a bit idealistic and not necessarily practical in a commercial environment. Agencies typically have to provide quotations for work to be completed, and clients will often have a bunch of requirements that they communicate to the development agency in one form or another. So whilst Henrik suggests that you run through a backlog and assign importance to each story, and then communicate to the client that all stories with importance > 50 will definitely be in scope, and everything below < 50 will possibly be included in descending order of importance, simply does not work in our experience with clients. Think of it like this, if a customer goes to two car dealerships to ask for comparitive quotations, the customer would expect like for like quotations that he can compare. When one of the dealerships comes back with a laundry list of features, but says something along the lines of: "We'll try our best to include air conditioning and a radio with your car, but until we get into the manufacturing phase we won't be able to guarantee you'll have that included as we don't know if we have enough materials at the price we've estimated", you can be pretty sure the customer will go with the other dealer who is making an up front commitment.
With easyBacklog, we help to ensure agencies can make commitments to clients about scope at the outset, but then manage change throughout the project allowing the customer to shift their focus in terms of what will be included within the budget they set out. This is achieved because:
Setting up an initial estimate based a complete backlog is trivial, the tool is fast, stories can be estimated with the 50/90 rule with the team, and experience in regards to typical team velocities can be used to estimate the number of days and potential cost for the project.
Once the project goes into production, the estimate backlog is used as a base moving forwards. Any additions can be made to the backlog, as can backlog items be removed or re-prioritised. easyBacklog ensures that snapshots of the backlog are made at any point in time so that you can easily sit down with a customer a review where the backlog was when they agreed the contract with your company, and where it is now, explaining all the differences and the motivation behind them (typically driven by themselves). Empowering your project managers with this functionality means a client can easily rectify any increases in overall budget by simply readdressing the backlog until it meets the contracted budget.
View an example screenshot of the snapshot compare feature >>
Section: Multiple scrum teams
Henrik talks about the strategy behind multiple teams or single larger teams, and the relative advantages of each. He says that the largest single scrum team they have had to accomodate was a team of 11 people, but he said that did not work too well as planning, demo and scrum meetings simply took to long, and with such a large team communication about what each person was doing was quite difficult.
easyBacklog does not currently suppport the notion of multiple teams, so in the sprint planning section currently there is only one sprint per date period. We'd love to hear from our users whether they need to support multiple teams, and if so it would be great to hear how you go about managing this and what easyBacklog could do to help with their planning? Please do tell us what you need.
Overall, we think this book is a great read for any team implementing Agile and Scrum as it talks about real world problems and how Henrik addressed them. The book would also serve as a great starting point for new teams who can delve directly into a working methodology that is being used by successful agile teams.
We'd love to hear how you think easyBacklog can help you manage your backlogs better and if there are any areas we could improve. Get in touch and tell us what you think >>
