Don't start your Sprint or Iteration on Monday

Monday seems like a logical time to start your Sprint, right? The start of the calendar week, rested after the weekend, let’s go! In reality it is a bad idea, and I will explain why…

Primarily it comes down to interruptions to the sprint cadence. The start and finish days of a sprint are the days where it is crucial that the entire team is in attendance. Everyone needs to know what we are doing, why, and to learn together from our mistakes.

Public or Bank Holidays usually occur on a Monday. If your sprint is scheduled to start on a Monday, which is also a Public Holiday, you need to reschedule all of the sprint meetings, shorten the sprint and this causes significant admin overhead and critically it interrupts your cadence. The other issue that often occurs is the impact of changes arising from Monday morning management meetings.  These changes hit the team just after they have started their sprint, resulting in re-planning costs, and a diminished sense of autonomy.

Fridays are bad too as this is often the day that people book off to extend their weekend into a mini break. Fridays are often the day that leaving lunches, leaving drinks and other celebrations occur, resulting in more impacts.

So instead of Monday, start your sprint on Wednesday or Thursday. The sprint end/start being the middle of the week has several advantages. It avoids the issues of Monday/Friday. Meeting rooms are generally more readily available in the middle of the week.

I do not recommend Tuesday because when there is a public holiday on Monday the sprint will effectively be ending the Friday before a long weekend (which is when everyone is mentally checked out).

So in summary avoid Mondays and Fridays it will save a lot of heart ache.

Photo Credit: Andrew_D_Hurley via Compfight cc

Focus on UX

I recently attended a session of the London Agile DiscussionGroup where the focus for the night was UX, what is it, where does it fit in the lifecycle of an agile project? To me it was a very interesting night as I have not worked directly with a UX designer before. I was intrigued to see how others have done it.

I was especially keen to know whether they had been able to work in a continuous manner (UX developed in the same sprint that it is applied to the product) as opposed to working sequentially (UX developed in Sprint N, UX applied to product in Sprint N+1). Going into the night I had seen couple of ThoughtWorks presentations on Continuous Design. However because I had never experienced it, I was open to possibilities on both sides of the debate. At the end of the night I had heard three tales of Continuous UX occurring in the wild and about 70% of the attendees believed that it will be possible for them to do Continuous UX in the future.

For me there were three key takeaways from the night:

1. Continuous UX is possible.
2. The key to Continuous UX is small User Stories.
3. UX needs to involve feedback from real users; ideally the feedback should be analytical data. Otherwise it is just guess work and not really UX.

From what I heard most UX is a case of cyclically incorporating the feedback/data into the on-going design and development work. There will be some UX Debt accumulate, but you need to keep it low as the cost of those UX changes can quickly sky rocket. In summary UX like architecture, needs to be a little bit ahead of the daily sprint work, but not sprints ahead.

One of the real life success stories I heard, was of a small team (1 UX, 2 developers & 1 QA) building internal system and working on small User Stories. The UX guy would produce working CSS of the item in half a day, and work with the team on refining it. They were able to deliver a continuous flow of changes that incorporated UX. The UX guy building directly into CSS and not writing down his ideas; was a large part of their success, along with their small stories that lead to simple UX.

Restaurant Booking Web site scenario

To put our new found knowledge into action, each table of participants at the meet up, took on the following scenario. As a new project team, create a web site for a local restaurant that allows them to take bookings for dinner. Outline the project plan sprint by sprint for the first couple of sprints. From my memory this is what we came up with as a team.

Sprint 0

•        Establish team
•        User Story Workshop & Project envisioning
•        Establish Infrastructure: hardware, coding standards, continuous integration, etc.
•        Deploy a hello world home page that is not published to DNS servers hence is only available to navigate to via entering the IP address.
•        Create architecture that allows for AB split testing and analytics capture
•        Create Brand Guidelines – style guides, reusable controls such as buttons.
•        Conduct Market Research

Sprint 1

•        Deploy a publicly accessible holding page that uses the brand guidelines, indicates that a full web site is under construction, shows the address, phone number and e-mail address of the restaurant.
•        Conduct AB split testing on some different holding pages.
•        Start working on the highest priority User Stories, incorporating UX as we went.

Photo Credit: http://www.flickr.com/photos/murdocke/

Communication during a transition

In summary it should be focused on what you hear not on what you say.


We recognised that communication with staff during an agile transition was important for two reasons; firstly so that the transition changes would be understood and accepted. Secondly and most importantly, so that issues and concerns from staff would be raised. We could only address concerns that we knew about so it was crucial that they were raised by the people who were feeling the impact of the changes.

Try as we might, deafening silence was the result of most of our communication approaches. 

While this blog post presents many communication approaches that failed to generate any feedback, overall the transition was a big success, with the results to prove it. The net positive survey response to ‘I am well informed about the agile transition’ rose from 70% to 84% and then to 90% over two years. However the ultimate indicator of success is that the vast majority of staff are really happy at work.

What I have taken away from all of this, is that communication should come from numerous channels and MUST be two way to be effective. It also brings to mind the Proverb "Listen to people twice as much as you speak." 

For those who are interested, the remainder of this blog explains the different approaches that we tried and a brief summary of the outcomes.

• Email feedback inbox – e-mails received in two years, zero.
• End of Transition Team sprint Email, explaining what we had done and are planning on doing. In there we linked to the feedback email address and mentioned that all of the Transition Team is open to being approached – feedback received, zero.
• Chocolates hidden behind links in the End of Transition Team email - we ended up eating the chocolates ourselves as no one found them.
• Directly telling people about chocolates hidden behind links – partial success, with some heavy hints, the chocolates were ‘found’ and handed out, excitement and interest created = zero.
• End of sprint Blog, explaining what we had done and are planning on doing - very few people subscribed to the blog.
• Transition Team members provided in person updates to teams after their stand ups – partial success, teams got the information and queried a few items; however where generally dis-interested and questioned why they get Management updates and Transition Team updates.
• Submit news to go in Management Update – un-tested by this time the Transition was wrapping up and only one news item was submitted, ‘the disbanding of the Transition Team’.
• Quarterly Staff speak ups – this generated a couple of questions but generally there was silence, at least they were there to hear the messages.
• Ask Transition team for concerns, who in turn asked Scrum Masters, who in turn asked team members – success, a reasonable number of concerns were raised. Many of these were turned into Transition Team User Stories.
• Surveys – ten questions one page, done via Survey Monkey, same survey three times over two years. Success: 80% of staff responded, plenty of meaningful and detailed feedback received. Many of these were turned into Transition Team User Stories.
• Rick Roll entire division in Transition Team farewell e-mail – good result, at least five people contacted me ;-)
• Scrum Masters discussing issues with their manager during regular 1 on 1s – success, plenty of issues where raised and then discussed by the Transition Team with several of these becoming Transition Team users stories and some guidance for stories already in progress or about to start.
• Division Manager holding Staff Forums with small cross functional cross team groups – a great success, staff really got stuck into providing direct and honest feedback. Some of this was related to the transition and other items were more general. This provided some Transition Team user stories and some guidance for stories already in progress or about to start.

Image Provided by: © Svidenovic | Dreamstime Stock Photos & Stock Free Images

Story Points are only one third of the reason for estimating

“One’s destination is never a place, but rather a new way of looking at things.”
From: Miller, H. (1957). Big Sur and the Oranges of Hieronymus Bosch

Assigning some Story Points to a User Story may seem like the point of agile estimation; however in my eyes it just signifies the end of the process. 

For me the goals of agile estimation are to build a shared understanding in the team of what the story is and to build team consensus around what the rough estimate in Story Points should be.

The journey that the team goes through to come up with the estimate, is more important than the number that is assigned at the end of the process. Sure the assigned estimate assists with planning, however the knowledge that the team gains during discussion will help with their understanding of what they are delivering, why and how they will go about it. I often hear discussions on topics such as: user needs, business value, design, potential new User Stories, testing approach, development approach, how this User Story fits into the Epic, which are all valuable.

Here is a brief summary of the benefits that the team gain by going through an agile estimation process.

Assigning Story Points to each User Story supports

• Grooming – identify stories that are large / candidates for splitting, identifying inefficiencies such as splitting an 8 pointer into two 5 pointers – should we do it as an 8 pointer to save overall time?
• Sprint planning – roughly creating a sprint backlog based on average velocity.
• Sprint planning – switching User Stories of equal Story Points in/out, up/down priority.
• Release planning – using the combination of average velocity and story points of remaining stories to provide a rough view of our status.

Discussions build a Shared Understanding, which supports

• Grooming – effective ways of splitting a User Story into multiple User Stories.
• User Story Planning – splitting user Stories into a set of tasks that will work for the whole team.
• Development – design ideas, implementation approach, testing approach, etc.
• Identifying issues – such as impediments, dependencies, etc.

Using consensus to arrive at the Story Points supports

• Sprint planning – with a stable average velocity and consensus on the Story Point of each User Story, there will be less second guessing of what to pull into the sprint.
• Commitment to delivering the Sprint Backlog – consensus around the estimate, leads the team owning the sprint commitment. i.e. “it was my estimate, so I will push to finish the story within the sprint”.

Interested in estimation?

• Fast Estimation
• Story Points do not equate to time
• Top Tips for Planning Poker

Iteration Manager to Iteration Leader

Scrum Master to Scrum Leader

Iteration Managers/Scrum Masters should not just be managing their team. They should be providing the team with leadership that helps them to achieve great things to together.

• Lead not by telling them.
• Lead by helping them to set clear and elevating goals.
• Lead by teaching an agile way of thinking.
• Lead by teaching them to think through the problems that you yourself contemplate.
• Lead by making them think for themselves.
• Lead by encouraging them all to be their best.
• Lead by example. I.e. exhibit the Scrum values. Be the change you want to see.

Self-organising doesn't mean they don't have an Iteration Manager, it means they can function without one. An Iteration Manager will always be there leading them onto a greater success then they could achieve by themselves. That is what great leaders do.

This article is available in presentation form on SlideShare: Iteration Manager to Iteration Leader.

Photo Credit: I was unable to find the owner of this photo. Please contact me if you own it.

Fast Estimation

Imagine you have just completed some Product Discovery work and have a pile of User Stories that need to be estimated. You look at the pile and think, wow that will take hours to estimate using Planning Poker. I just want rough estimates so that we can put together a release plan. We know the plan will change in the future, but we need some starting point. What can I do? 

The answer is Fast Estimation. 

Fast Estimation is derived from Planning Poker. With some preparation and a 1 hour workshop it is common for a team to estimate about 30 User Stories. Teams I have worked with have successfully used it to estimate new functionality, automation of processes, improvements to internal practices and organisational change work.

While estimation is the main objective of the Fast Estimation process, another significant benefit you get for free is Shared Understanding. By this I mean the discussions that occur help to clarify in the minds of the team members what work is required, how it inter-relates and how big the entire backlog is. The knowledge that is gained about the backlog as a whole can often be more valuable then the estimates assigned to individual User Stories.

Fast Estimation Process

Preparation
Write out the User Stories to be estimated onto Index Cards of the same colour. A short cut that often works well is to just write the Title of the User Story on the index card and have the details of the User Story on hand during the session (i.e. in an electronic tool, or a printed spreadsheet, etc).

Find one to five Reference User Stories. These are User Stories that are well understood by the team and will act as a reference point for the upcoming comparative estimation. Ideally the team will have recently completed those User Stories or have at least estimated them in Story Points. The Reference User Stories should have differing Story Points, ideally being in the 2 to 20 range. I recommend at least three reference User Stories and usually aim for five, however you can get away with one. The case where your team is new and does not have any reference User Stories; sounds like a topic for another day. If you are really stuck just pick a User Story that you think is 3 Story Points, and use that for your Reference User Story.

Write out the Reference User Stories onto Index Cards of a different colour to the cards used for the User Stories to be estimated.

Schedule a 1 hour meeting in a room that has a long table, big enough for the team to gather around.

During the workshop
Set the scene for the workshop by explaining the following points

• The objective of the workshop is to roughly estimate this stack of User Stories (show them the stack of Index Cards so that they can see how many there are), this will help to emphasise that time is of the essence. 
• Fast Estimation will only rough estimates for these User Stories. 
• There will be lots of assumptions and hence the estimates will not be very accurate.
• The team will get another chance to re-estimate these User Stories in normal grooming session prior to starting work on the User Stories.

Layout one set up Planning Poker cards on a long conference table in ascending order i.e. 0, 0.5 .. 110, ∞.  It is a good idea to leave more space between the lower / middle numbers as hopefully more of the User Stories will end up there. If there are lots of User Stories at the large end of the scale that is a whole different problem, good luck with that ;).

Place the Reference User Stories below the Planning Poker card that corresponds to its Story Points. As per the picture below.

Picture 1: Planning Poker cards and Reference User Stories, with un-estimated User Stories at the bottom.

Confirm with the participants that they understand the Reference User Stories and agree with the Story Points for each. You may need to adjust one or more of these. Once you progress past this point, do not change the Reference User Story – Story Points any more these are now set in stone.

Divide up the User Stories roughly and hand them out to the participants.

Give the participants a couple of minutes to quickly read their set of User Stories to themselves.

Pick someone at random and ask them to read out their User Story and then place it underneath the Planning Poker card that corresponds to their estimate. Only allow a brief time for this. Ask the group if they are happy with that estimate and discuss/move it as necessary. Encourage participants to move the card if they disagree and to explain their justification at the same time.

Picture 2: First User Story Estimated

Ask the group if there are any similar User Stories in peoples stacks. If so, repeat step 8 for those User Stories. Once there are no more similar User Stories pick another person at random and repeat step 8 for that User Story.

Work your wait through all of the User Stories, placing and discussing, finding similar User Stories, etc. etc.

Once all of the cards are all in position you can quickly write the Story Point estimate on each Index Card and gather them up.

Picture 3: All User Stories estimated 

As a final wrap up to the meeting it is again worth mentioning that the team may need to re-estimate these User Stories using Planning Poker before taking them into a sprint planning meeting.

A variation I have tried that did not work as well
After handing out the index cards, everyone places their cards at once in a big rush of activity. Then the team discusses them and re-estimates them as appropriate. This approach raises the energy in the room but it is a bit more confusing. Individuals will find it confusing to place their cards without the understanding of the backlog that they build up while discussing the User Stories one by one. The benefit to this approach is that very rough estimates are assigned to all of the User Stories up front, so if you run out of time at least you have everything estimated.

Teaching Fast Estimation
I have an example game to teach people Fast Estimation which extends on the fruit estimation of Planning Poker that I learnt in the Certified Scrum Master course taught by Rowan Bunning.

Write out the following Items To Cook on Index Cards, and place ‘B.L.T’ your three Story Point Reference User Story  (I have found that due to the simplicity of these User Stories 1 reference story is enough). 

Ask the participant to estimate cooking these items from scratch. I.e. for Eggs Benedict they are expected to make their own hollandaise sauce. Guide them through the Fast Estimation process,  this game usually takes less then 10 minutes (provided the participants are familiar with Planning Poker and Story Points).

Items to Cook

• Eggs Benedict
• Tin Baked Beans
• Fruit Salad
• B.L.T.
• Crispy skinned Salmon
• Poached Eggs Soufflé
• Cheese Burger
• 64 Cup Cakes
• Garden Salad
• Alacarte, 3 courses for two
• Cheese Cake
• Duck Ala orange
• Caesar Salad
• Alacarte, 3 courses for ten
• Lasagne
• Pineapple upside down cake
• Burrito’s
• Mashed Potato
• Beef Korma
• Banoffee Pie
• Fish & Chips
• 12 Fancy cup cakes

Interested in estimation?

• Story Points are only one third of the reason to estimate
• Story Points do not equate to time
• Top Tips for Planning Poker

Related Reading
I can recommend these blogs for other great approaches to estimating stacks of User Stories:

• Steve Bockman - Team Estimation Game 
• James Grenning - Planning Poker Party 

Training available in South East QLD, Australia

If this article was interesting to you, then your team would likely benefit from face to face training on Agile Estimation. I run a one-hour Agile Estimation training session, that is highly interactive, immensely fun and teaches the foundation of agile estimation along with how to effectively run Planning Poker as well as Fast Estimation. Please contact me to set up a training session for your team: andrewrusling@hotmail.com

User Story Centric Stand ups

As a Scrum team learns to work closely together and to focus their efforts they tend to only have a couple of User Stories in progress at any one time. Working collaboratively with limited work in progress brings several benefits, namely increased shared understanding and a reduced risk of partially completing a User Story.

Unfortunately when Scrum Teams work closely together on a couple of User Stories, their Stand Up Meetings become disjointed. By this I mean that as each person answers the three questions, several people will need to speak out of turn to present a full view of what is occurring and what needs to be done.

The standard format for Stand Ups where each team member answers the three questions in turn is a Person Centric approach. The standard format is a great way to teach those new to Scrum what information they are expected to provide, what information they should seek and what planning they should carry out.

However when the Scrum team works closely together on User Stories the Person Centric Stand Up no longer represents how the team is working.

Teams use their task board to visually represent the work they are doing and how they do it. I recommend that Stand Ups should also represent how the team is working. Hence when a team is collaborating closely on their User Stories I recommend the team switches to User Story Centric Stand Ups.

User Story Centric Stand Ups

1. In priority order discuss each User Story

        A. As a team update the work that was done since last stand up.

        B. As a team plan the work for today.

        C. As a team discuss any impediments relating to the User Story.

2. Ask the team if there are any other tasks that have popped up.

3. Ask the team if there are any other impediments. I.e. Impediments not directly relating to a User Story.

4. Ask the team if everyone has a clear plan for what to work on next.

This Stand Up format fits in easily with teams that are used to answering the three questions and have moved onto collaborating around User Stories.

User Story Centric Stand Ups are not recommended for new teams, only for teams that are comfortable with the Person Centric Stand Up and work collaboratively around a couple of User Stories.


Photo by: Kris Anderson