Strike Force sprint planning

Today, I had the opportunity to facilitate the sprint planning of our newest team in Orange & Bronze, which we affectionately call “Strike Force”.  We recognized that we can be more responsive in dealing with new opportunities that come our way, as well as more deliberate in supporting our long term commitments and initiatives, to which this is our response.   The first assignment of Strike Force is the completion and integration of our internal systems, and Scrum was introduced to the team as a means to deliver Potentially Shippable Code in a predictable manner, as well as allow the Team to better understand how we as a company aim for doing software engineering right.

We took time to learn more about Scrum as well as the system to be built before we proceeded with the actual sprint planning.  We did not have the luxury of an actual Scrum course, and so we both learned and then applied them as we went along.  I had some observations on how things were done earlier:

Agile Manifesto, and the three pillars of Scrum

Traditionally, I would explain Scrum by how the process goes: sprints, meetings, daily scrums, and the like.  The biggest issue here is that teams thus do not understand the motivation behind Scrum and why it is structured this way, making process improvement impossible as the goal of the process is not clear.

We approached Agile and Scrum by starting with the Agile manifesto and then the three pillars of Scrum: inspect, adapt, and transparency.  “We are uncovering better ways of developing software by doing it and helping others do it”, the first line in the manifesto, was stressed as this is what we should aim for when doing Agile software development.  We then moved to the three pillars and how Scrum is structured to allow these to happen.  This was highlighted by an explanation on where Scrum came from, from rugby, and how it is done in real life.

I hope that the stress put on the points above will give the Team a litmus test to check if any changes, improvements, and decisions they will make are in line with what they are doing.

Breaking down user stories

There seems to be two camps on how user stories are broken down: as tasks with hour estimates, or as smaller stories with story points.  My CSM training focused on the former and this is what we did.  During Part 1 however we came across a story that the Team felt was too big and thus was broken down.  I wondered how this would affect Part 2 if we hadn’t approached it using the former.

There are three parts in a product backlog: DONE, fine grained stories, and finally coarse grained stories.  A product backlog is periodically groomed in order to prioritize as well as break down stories.  I suppose what happened earlier was to be expected as this was the first time the backlog was groomed by the team and the PO.  I’m interested in seeing how Part 1 is carried out with a properly groomed backlog, as time that was supposed to be used to groom it can be used in other ways.

During Part 2 the Team started discussing some possible implementation concerns with one of the stories.  We were able to agree with a plan of attack for that and continued on with Part 2 and within the time box.  What was highlighted after task breakdown and time estimation was that we need to look at the story level more and less on the task level – stories must be finished first before moving on to the next one.   This set the tone for the discussion on team velocity as well as Big Visible Charts.

One of the developers in the Team asked how tasks were assigned.  He came from another company and just joined us recently.  I responded that you grab one from the board once you are done with your current one.  This prevents people from only focusing on tasks assigned to them and not on working as a team to get the sprint done, and was what he also observed before.

We discovered that double sided tape is very bad for index cards, so we need to make sure we have a supply of masking tape.  Also, we figured out a good way to focus on the stories by grouping and hiding tasks under them.  Once the story is to ready to be worked on would we then reveal the tasks in the board.

Acceptance tests in user stories

User stories are promises to talk in the future.  They are a quick way of capturing what we would like to see in the system without too much definition to allow us to start working on it as soon as possible.  They are short and simple and without detail by design, and should be complimented by acceptance tests to verify them.  I don’t think we have been that good on capturing these acceptance tests in the past.

We were estimating a story to generate a report in the system.  We did not have full confidence in assigning a story point to it as we weren’t sure of the details – an expected scenario with user stories.  The team finally asked our PO on how he envisioned report generation would work: how do we access it?  How should it look it?  How is a user going to use it?  With this we were able to get a better idea on how the story would end up and thus have an estimate.

I got introduced to Acceptance Test Driven Development, specifically Robot Framework, during my CSM course, and one of the tenets on this is to as the customer examples on how a story is suppose to behave.  This would then lead to a customer-focused acceptance test that can be automated using tools such as Robot.  We are still exploring how to add ATDD to our teams but the idea of using examples can be used to make user stories more relevant.

I asked earlier on what we can do with time freed up from grooming the product backlog and I realized that this is it.  We weren’t able to do this effectively as we took time to groom the backlog but I hope to suggest this to the team and PO in the next sprint planning.

And that’s it.  Once we finished with Part 2 we went back to the Strike Force area which already had whiteboards and other tools so the team can start work.  They are off to a two week sprint and we had two hour time boxes, one for planning Part 1 and one for Part 2.  Daily Scrum time was agreed by the team and the PO was informed on what they think is possible for this sprint.  Looks like they are ready to go and I wish them well on their sprint :).