Talk Agile

User Stories

In sports a player on a team is focused both on the “now” and also on being proactive about their next move during active play.  A basketball player is dribbling (the “now”) while planning their next move.  In volleyball, a player is getting ready to receive or block (the “now”) while also planning on a pass or spike (proactive).

In an Agile process, a team is actively implementing a user story (the “now”) while also looking forward to what is coming next (proactive).

1)    System Analyst – While the person filling the System Analyst (SA) role on the team is supporting the rest of the team in implementing the current User Stories, they also should look ahead at least 1 Sprint.

a.    Are the upcoming User Stories ready?  Is there enough information for the team to task out the story in the upcoming planning meeting and can test cases be created based on the information around the story?

b.    Has the upcoming User Story been sized by the team?

c.     Are there good Acceptance Criteria with the User Story?

d.    Has the team had a chance to review the User Story?

2)    Team – The rest of the team should also look ahead to see what is coming next.  As the SA identifies stories ready for the next Sprint, I recommend the team review them before Sprint Planning meeting.  Don’t spend more than 5 minutes on each story just to get familiar enough with them prior to the meeting.

Meeting Management

We all enjoy working on things most interesting and fun to us.  I consistently hear feedback and concern about meetings from teams such as; a) We have too many meetings, b) Meetings interrupt our real work, c) We don’t have enough uninterrupted time to do the fun stuff (programming and testing).

Meetings are important so let’s focus on ways to make them more effective.  With a few simple changes we can help with the above.  BTW – you are not alone in wanting more out of meetings. Here is an article written by Jean Tabaka on the topic.

1)   More time for the “fun” stuff – Teams that run two week sprints have 10 business days in each Sprint.  Moving to an “All in One Day” meeting model is one way to help with the concerns listed above.  Now you have 1 day of meetings and 9 days of time to spend on the “fun” stuff.

2)   Uninterrupted Time – Try blocking off time on a daily basis for your team.  This would be non-meeting time to focus on development and test and gain momentum.  Just as an example, one particular Scrum team set aside time every day from 3 to 5 on the corporate Outlook calendar.  This was set up a tentative meeting on their calendar so IF a team member is needed in a meeting by someone, the scheduler of the meeting saw they were tentatively booked and had a conversation with them before scheduling.  This rarely happened once on the calendar.

3)   Non Effective Meetings – If your meetings are taking too long, you are going over the time allotted or you are not getting things done in the meeting you planned to do, try the following:

a.   At beginning of meeting write the Purpose, Goal(s), and Agenda for the meeting (5 min)

b.   Help each other stick to the Agenda (all meeting long)

c.   If important topics come up not related to the Purpose of the meeting, write them down in a “Parking Lot” for consideration later and keep your meeting focused (one person take lead to write these down)

Focusing on Team and User Story 

This is all about giving your full focus and attention to the work you do.  While it isn’t necessary about multi-tasking in general it is about focusing on the right stuff at the right time.  If you’re interested in a short fun look at impacts of multi-tasking, read this blog and see if you can relate –  or another one

1)    Team – As a team, focus on the top priority story and its tasks first before moving on to the next priority story. There are certainly exceptions to this, for example, when you might “trample” on each other’s code and in those cases stay focused on the top few stories.  Why is this important? Being 90% done with all User Stories at the end of each Sprint is a much different statistic from being done with 80% of your stories at the end of every Sprint.

a.    90% done with all User Stories would be like having 5 User Stories in your Sprint and for each User Story you have all but 2 or 3 tasks done.  None of them are completely finished as time was focused across all stories. (BAD)

b.    80% of stories done would be like have 5 User Stories in your Sprint and having 4 out of the 5 completely finished because the focus was getting the top priority story done before moving to the next story. (GOOD)

2)    Meetings – Focus on the purpose, goal and agenda of every meeting you are part of.  Move your way through meetings quickly and maintain focus.  Since invitations to each meeting are based on its purpose, keeping the meeting focused and on track benefits everyone involved.  If items not related to the purpose of your meeting come up, as they typically do, add them to the “Parking Lot” and schedule a new meeting to handle those items.

Automation Possibilities

Two initial areas for automation are deployment and testing.  Why?  While not necessarily easy, these two areas have a path towards automation which is easier to identify so let’s start with them.

1)    Deployment – identify ways to automate your deployment process. Start with deployments to your Development environment. Conquer it!  Next, move on to automating deployments to your Integration environment.  Conquer it!  Now improve the approach taken for Development and then Integration.

2)    Testing – meet as a team to come up with a plan and goals for automating your testing.  This starts with Unit Tests and moves its way all the way to GUI automated testing.  Decide what your long-term goal is (your Epic User Story), then decompose the Epic in to smaller user stories and pick the first one to tackle.

Testing Playbook

This could also be called the Sprint Playbook but since the end goal is having more and more of your tests pass, I chose the term Testing Playbook.  Let’s take a look at a typical Sprint Planning day for most Scrum teams.

Sprint Planning I – The Product Owner meets with the team and talks about the upcoming User Stories.  During this time the team asks questions about its purpose and intent and reviews the Acceptance Criteria.

Sprint Planning II – The team takes the information they learned from their Product Owner and identifies the tasks needed to complete each User Story.  Developers focus on their tasks while QA focuses on their tasks for each User Story.

Sprint Planning III – The team shares what they are committing to complete in the Sprint with the Product Owner.  Any additional questions, answers or clarification topics are usually discussed.

Now it is off to the races.  The developers have interpreted what they believe are the tasks needed to meet the Acceptance Criteria for each Story and work hard to get them all done as soon as possible.  The QA team member comes up with their Test Plan and starts to write Test Cases that will be run as each Story is completed.  Each typically works off of their own interpretation of the User Story.  The result is that when tests are run towards the end of a Sprint, some bugs identified are simply due to the Developer tasks and the QA tasks not being written off the same playbook.  This is especially true when the Acceptance Criteria are missing or not as detailed as they could be.

Below is a diagram showing my recommended approach.  It boils down to ensuring communication around Test Strategy and Development approach occurs at the very beginning of the Sprint for each User Story.

Thanks in part to Tim Korson, with QualSys Solutions, for inspiring a graphical way to illustrate what I had been coaching.