Rules to Better Scrum using TFS

​​​​​​

Hold on a second! How would you like to view this content?
Just the title! A brief blurb! Gimme everything!

SSW's Rules to Better Scrum​​ allows businesses to address their most important challenges first, and respond quickly to change. Our rules advocate software consultants working on-site, or on the phone, so long as there is close consultation with business users, with the goal to become integrated members of the client's team.

Software must help a business become more efficient and build better relationships with their clients. Business need software to be produced cost-effectively and quickly. Simple steps upfront stop software being slow to build and difficult to change.

Read our rules on Scrum (project management) for some simple tips before starting your next project.

Adam Cogan, SSW Chief Architect

Figure: Classic stories of Project Management
  1. Getting Started - Have you read the Scrum guide?

    ​​​Everyone who will be involved in Scrum (pigs and chickens alike) should have read and understood the Scrum guide.

     

    Understanding the concepts of Scrum is easy; implementing it is hard!
    Figure: It's handy to know who the pigs and chickens are. The word "commit" and this silly chicken and pig story, were removed from the Scrum Guide 2011.

     

    Everyone should:

    1. Read the Scrum Guide.
    2. Take the Scrum Open assessment and get at least 75% to be “Certified Scrum 1”
    3. Watch the awesome video 'Scrum in 10 minutes'  
  2. Do you know that working in a Team is better than on your own? (aka The Ben Darwin Rule)

    Is working as a team all it is cracked up to be?

    It's a well known fact that a good team of 3 people will output more than 3 people working on their own. As well as that, the team members will find it more rewarding as well.
     
    The best sum up of this was by famous Wallaby player, Ben Darwin, who said: ​​​​​
    I found the hardest issue of all was that I missed my friends, basically, and that's what I told them when I gave them the jersey for the final. I just missed the 14 guys. There's a feeling that comes in sport, particularly in team sport, where we say we feel jealous of the wages of individual sportspeople but never jealous of the lack of team. When you finish a game of football and you've played together and you walk off with the other 14 men, the guys on the bench, and you've overcome an opposition, you don't have to say anything to each other. You can simply look your fellow man or other player in the eye, and he knows you helped him, and you know how he helped you. That's enormously satisfying, and I haven't found that anywhere else in life.

    Ben Darwin speaking on how, after breaking his neck in a scrum, he was forced to quit being a Wallaby and rejoin normal society.


    We can see examples of this in nature as well. For the Antarctic Emperor Penguin, cooperation is the key to survival. Every winter thousands of male penguins huddle together to share warmth. The birds on the most exposed side of the huddle gradually move down around the huddle to the more sheltered side. This means that each bird spends some time exposed to the full force of the Antarctic winter, but then gets its fair share of warmth in the middle of the pack. These clever birds understand that by taking turns and enduring discomfort in the short term, their chances of success (survival) greatly increase.

    It is essential that in order to be a contributing member of a successful team, you are willing to put the good of the team over your own interests so that everyone can benefit in the long term.

    See http://www.youtube.com/watch?v=cgGL6SbMfKc

    Note: If this beautiful story is not up your alley you will prefer a similar example of working as a team by the IT Crowd http://www.youtube.com/watch?v=pGFGD5pj03M  

    Tip: Leverage Existing Organizational Experience and Learn From the Best.
    Does your company have a ‘super star’ team? If so, why not ask to sit in on one of their meetings, or take a few of their team members to lunch and ask them for advice on increasing your own team’s performance.

    Suggested questions to ask the experts:

    • What do you define as success?
    • What are the things that you do not worry about?
    • What practices do you believe lead to your success as a high performing team?
    • Do you have defined/document practices and procedures that you follow?
    • What tools do you use that contribute to your effectiveness?
    • What metrics do you use to measure your success ?

    With the rest of your team, prioritize the feedback you received and select a few key items that you can implement right away.
    Make a backlog from the feedback you received, set some goals and start your team on the road to being ‘Superstars’ too.

  3. Do you know the 8 Steps to Scrum?

    ​​Scrum is easier than it seems, we'll explain how in these 8 simple steps.

    Fi​gure: This Scrum image includes all the important steps from the initial meeting to the Review and Retro. Print this SSW 8 Steps to Scrum PDF and put it on your " War Room" wall​
    1. Initial Meeting

      The Product Owner explains the product vision, scope is agreed, and the number of days needed for the 'Backlog Construction' is proposed.

    2. Backlog Construction

      A 'Backlog Construction' is performed, listing the features, technologies and a ball park of the number of sprints. Together with a rate, this becomes the estimate.

    3. Sprint Planning

      Features are ordered by the Product Owner. The Development Team estimates and forecasts which features will be delivered in the Sprint.

    4. Sprint

      The Development Team works on features in priority order, having done a Daily Scrum and sending 'Done' emails once the 'Definition of Done' is met. A task board is often used. During this process, the team also refines items in the Product Backlog to ensure they conform to the 'Definition of Ready'.

    5. Sprint Review

      The Development Team demos all the features they've completed. Feedback is gathered. This is the real measure of the success of the Sprint.

    6. Product Increment

      Work accepted by the Product Owner can be deployed to production. Each Sprint is a potentially shippable increment of software.

    7. Product Feedback

      Bugs and small changes are added to the current Sprint. Other requests are added to the Product Backlog if approved by the Product Owner.

    8. Sprint Retrospective

      This is the best part: Inspecting and adapting. Upon finishing the Sprint, the Scrum Team discusses what went well, what didn't and what to improve.

    retweet
    Figure: If you like this, retweet ​t​witter.com/AdamCogan/status/375010501693960192​
  4. Do you know how to be a good Product Owner?

    ​​The client is generally the Product Owner (PO). They should read the Scrum Guide and​ watch the Product Owner video to understand their role. It is so important to the success of their project:

    In order to be a good PO, they need to:

    1. Be available for Sprint Reviews, Retrospectives and Sprint Planning meetings (approximately half a day for these 3 meetings, for each 2 week sprint).
    2. Order the Product Backlog. The important things will be done first, in order to maximize the ROI as the budget will run out one day.
    3. Be available, at least remotely, to unblock a developer if he has questions/impediments. A good PO has a feeling of urgency.
    4. Ideally listen in on Daily Sc​​rums. This is o​ptional but means that the PO will have daily insight into the team’s progress.
    5. Understand Product Backlog Items (PBIs) and be able to explain what they want using Accep​​tance Criteria. This is the main way that developers and POs sync their understanding of what needs to be done.
    6. Agree on a Sprint Goal for each sprint.
    7. Not influence (or anchor) developer estimates with comments like “this one will be easy” and allow the team to come up with converged estimates.
    8. Respect the Spri​​nt Goal. Understand that the team will only work on things in the Sprint Backlog and don’t expect other things to be done as well. Most things can wait for the next sprint.

    Who should be the Product Owner?

    It’s hard to give guidance on who in the company would make a good PO. The usual candidate is often extremely busy. It should be:

    1. Someone with a personal stake in the success of the project.
    2. Someone who is available
    3. Someone with a clear vision of the product,
    4. Someone who has authority with budget. E.g. They could authorise adding a designer to a sprint for a couple of days
    5. Someone who has read the Scrum Guide and watched the Product Owner video and understands the role.

    It’s possible to outsource the role of PO to someone in the development consulting company, but this is not recommended. Don’t put the fox in charge of the chickens.​

    ​ “Most dysfunction I see in Scrum teams is caused by a bad Product Owner”

    Adam Cogan during Teched session.​
    Professional Scrum Trainer, Scrum.org

  5. The Team - Do you help your Scrum Master protect and serve The Team?

    Part of the Scrum Master's (not ScrumMaster's) role is to protect the team from distractions so they can deliver on their commitments, to ensure agreed process is followed and to help all roles keep their promises.  ​​

    It is also important that team members do not allow themselves to get distracted and must work based on priority. 

    Here is a good saying to remember: "It is very important I complete my sprint. Can this wait 1 week until the next sprint?".

    Any requests for work or distractions outside the scope of the project that take more than 15 minutes must be declined politely and the distraction notified to the Scrum Master, or, if the request comes from the Product Owner, it can be added as a new PBI as described in https://rules.ssw.com.au/are-you-flexible-with-the-order-you-do-the-work-(i-e-cancelling-a-sprint) 

    The only exceptions, where a Team Member can start the work before notifying the Scrum Master are:

    • Any critical production issues that absolutely requires the attention of the Team Member and nobody else is available
    • A client request for work when the Team Member is working on an internal project
    • Test please requests, if the total time taken from the Sprint for all Test Please requests is less than 8 hours

    In these 3 exceptional cases only, even if the Team Member doesn't get a response from the Scrum Master, the requestor can insist that the member starts the other work immediately.​

    ​​​

    For details on promises, see the rule “Do you understand the implied contract (promises) between Members of the Scrum Team?”

  6. Do you have a war room? (summary)

    ​​​The scrum team needs a place to gather for all the scrum ceremonies. This room should have useful information on the wall to help the team work more efficiently. We recommend having the following:

    Bad Example – No Product Roadmap is on the wall, so people can be out of sync with the future plans of the Product Owner Good Example – The Product Roadmap is visible at a glance
  7. The War Room - Does your development room have an electronic task board? (Physical is OK too for small, co-located teams)

    Having an electronic ​​​task board makes it easy for developers to keep track of tasks.

    These are the columns (aka swim lanes) you need:

    TFS Preview Task Board.png
    ​​​Figure: Good Example - a virtual client task board in action (TFS​)​
    TaskBoard
    ​​Figure: OK​ Example - a physical client task board in operation

    Near your task board, stick an SSW "Want to submit a User Story?"

    • Where to find their project portal
    • Who to contact with questions​
    • How to add tasks to the task board

    Print out this PDF and fill in the 2 fields and stick it on own task board.

    Figure: Create an avatar for each person and stick them on the current task. You can find our User Story Cards here. You can write the TFS work item ID on each card.
  8. The War Room - Does your Scrum room have the best Scrum image?

    ​​​We all know that a visual image can make a complex process easy to understand. Having a visual image of the Scrum process helps everyone, including the product owner and interested stakeholders, understand the process and make sure the steps are being followed.

    Here is an image for your war room wall...
    bad scrum
    Bad Figure: This image doesn't include the review and the retro
    scrum process
    OK Figure: This Scrum image is OK because it includes all the important steps including the Review and the Retro
    8 steps to scrum
    Good Figure: This Scrum image includes all the important steps from the initial meeting to the Review and Retro. Print this "SSW 8 Steps to Scrum pdf" and put it on your 'War Room' wall
    retweet
    Figure: If you like this, retweet ​ t​witter.com/AdamCogan/status/94109372908711936

    Related Links

  9. Do you have a Product Roadmap?

    A product backlog is a great way to see the fairly small broken up PBIs (Product Backlog Items) that make up your team's to do list but it can be a bit too zoomed in.

    ​To get a better zoomed out look, you should have a product roadmap. This could be using TFS Features or Epics, sometimes also known as MMFs (Minimum Marketable Features), but the concept is the same... 

    What is the priority order of the main feature groups that you will be working on?​

    Features.jpg
    Figure: ​TFS PBIs organized​ by Features to see a long term Product Roadmap and high level priorities
  10. Scrum Master - Do you schedule the 3 meetings?

    ​​​​​The Scrum Master (not ScrumMaster), must schedule the Sprint Review, Retrospective and Planning meetings.

    Estimate how much time each meeting will require, then schedule a single calendar appointment to cater for the three meetings. When scheduling the calendar appointment, keep in mind the following:

    • Ideally, each of the three meetings should be time boxed to an hour for every week of their associated Sprint.
    • This time boxing does not mean the whole time will be taken up, just that you should not let the time for each meeting be exceeded.
    • With the Product Owner's help, the Scrum Team will need some time to update the Product Backlog after the Retrospective and before the Planning meeting.
    • People need breaks.
    • The Sprint officially finishes at the end of the Sprint Review m​eeting. The Sprint Retrospective marks the beginning of the next Sprint.
    • These meetings do not necessarily have to be held on a Friday or Monday. You can have a Sprint start and end on any day of the week.​

    Tip: It can be helpful to finish the Sprint Review with the first D​aily Scrum​

    Schedule the meeting and invite the Scrum Team and any interested stakeholders.

    Required Attendees: [Scrum Team]
    Optional Attendees: [Interested Stakeholders]
    Subject: [Project Name] – Sprint Review, Retro and Planning Meetings

    ​​​​

    Hi XXX,

    This is a calendar appointment to hold the following three Scrum meetings:

    Sprint Review Meeting
    We will go through the user stories that have been completed and demonstrate them.
    See rule What happens at a Sprint Review Meeting?

    Sprint Retrospective Meeting
    Sprint closed and new sprint starts.
    We ask for feedback of the previous sprint so that we can ‘Inspect and Adapt’.
    See rule What happens at a Sprint Retrospective Meeting?

    Sprint Planning Meeting
    We go through the backlog (aka to do list), get more information, estimate and then prioritize.
    We then breakdown to tasks and commit to what we believe we can deliver for the next sprint.
    See the rule What happens at a Sprint Planning Meeting?

    ​​

    <This email is as per the rule Scrum Master - Do you schedule the 3 meetings?​​​ />


    Figure: Good Example - co​py this appointment template and send to ​the Scrum Team
    In Scrum, there are 4 meetings in total that you need to know about: 
  11. Product Owners - Do you know the consequence of disrupting a team?

    Disrupting a team member can affect the delivery of the whole sprint. Product Owners should always avoid giving tasks outside the sprint. It may seem to affect just one member, but it does affect the entire project.

    On Scrum, the team commits to deliver some set of functionality by the end of each sprint and the whole team is accountable for what they engaged to deliver. Missing a team member, even if temporarily can affect the whole sprint and if effects are considerable, the Scrum Master will recommend cancelling the sprint or removing stories to be delivered. Product Owners must be aware of how Scrum works and understand the importance of keeping the team focused on their tasks.

    Team members need to be completely transparent with the PO, the SM, and the rest of the team. Even if someone offers them a free trip to Iceland, they still need to ask permission from the Scrum Master.

  12. Product Owner - Do you know how to update the backlog?

    The Product Owner is responsible for updating and managing the Product backlog.

    There are three options:

    1. Team Web Access
      https://tfs.ssw.com.au/tfs/​
      image
      Figure: TFS Web Access is the best way
    2. Emails
      This is a very poor way to access and update the backlog as you can’t order the em​ails by business priority.
    3. Team Companion

      Figure: Team Companion lets you edit work items right in Outlook

    Decide whatever works best for you; SSW recommends using the backlog directly via web access

  13. The Team - Do you encourage multi-skilled teams by leaving your comfort zone?

    When selecting their tasks, team members should be looking to extend their skills. Scrum encourages multi-skilled workers, rather than having testers, back-end developers, designers etc. In other words, all team members should be able to help completing any task.

    This does not imply that everyone is a guru in everything; no doubt some people are especially skilled in a specific area, but team members work together and should be learning new skills from each other.

    During task generation and estimation in Sprint Planning, choose something new and ask someone experienced in that area to have a subtask to help you. 

    This is to make the team multi-skilled and reduce dependencies on individuals​.

  14. Planning Meeting - Do you encourage spikes (aka investigation tasks) when a story is inestimable?

    Sometimes it can be unclear to The Scrum Team whether a Story can be completed as required. For example the story "automatically package with Wise after the automatic build" requires investigation and experimentation to see if this is possible and to provide a meaningful estimate for the original.

    Schedule time to dig a little deeper. There's always another layer to uncover Figure: Schedule time to dig a little deeper. There's always another layer to uncover

     

    How is experimentation done? In agile software development, when you have an unknown, you do a spike story. A spike is a time boxed investigation with the output being the answer to an experiment or investigation and the resolution of an estimate for the original story.

    It is then best to write a new story “Investigate whether it is possible to automatically build with Wise”.  This story can be more accurately estimated and the result will allow the original story to be estimated or revised.


    Figure: Bad example – I want you to implement something, but I am not going to tell you what it is. How long will it take?

    To embark on the original story when it is inestimable would be irresponsible and leave The Team with a potentially impossible story and the risk of a failed sprint.

    All investigating stories must be timeboxed otherwise the process of investigation can meander and never come to a conclusion.


    Figure: Good example – The spike (time boxed investigation) comes first as it is impossible to estimate implementing something you do not know

    Note: This gives you work for future Sprints

    Tip: There is a further benefit of tagging 'spike' tasks with a consistent label. If your company takes up R & D tax incentives, then you need to be able to query for activities that were 'of an experimental nature'. In Australia this is a 15% credit on each dollar you spend on a developer.

  15. Estimating - Do you break large tasks into smaller tasks?

    A task should never have an estimate of more than half a day (4​ hours).

    If you have a big task with an estimate of more the 4 hours, you should consider breaking it in sub-tasks. In case the estimate has changed during the sprint, the “Remaining Hours” field must be updated in order to have an accurate Burndown chart.

    The reason Scrum limits the maximum hours is because you should always know in which task you are working and we believe one single action that takes more than 4 hours might be too generic. Refer to Do you create tasks under 4 hours? to know more.

  16. Estimating - Do you know what to do when you believe that an estimate for a task seems risky or low and you are tempted to add some contingency?

    You should always breakdown a task, by creating sub-tasks, until you are comfortable with the overall estimate. Alternatively, instead of making an unknown estimate, create a task first to investigate.

    The reason for having this feeling is that the task is not broken down enough and appears difficult to breakdown because there are unknowns.   For a simple example, a task of a story is to produce something for the story and it is not known how yet.  Rather than put an estimate for the task that seems risky or low, break it down into at least two-sub tasks of:

    • Investigate best option to produce result
    • Implement best option and produce result

    The estimate for the second sub-task might be tough but you must make your best estimate to ensure the burndown is as accurate as possible.  Once the first sub-task is complete then the second sub-task can be updated in both description and estimate as appropriate.   Other people can then clearly see what is transpiring.

  17. Estimating - Do you know how to size user stories effectively?

    ​​A team knows how many stories they can commit to by measuring their velocity. The Team estimates the highest priority stories in the Product Backlog in Story Points. ​It is very important for teams to estimate tasks effectively. There are several methods for estimating:

    • Shirt Sizes
    • Fibonacci Extended (1-100)
    • Fibonacci Original (1-21)
    • Doubling
    • Thr​own

    Let's go through them:

    Shirt Sizes

    This method is popular with Microsoft teams, but it has the problem of not easily mapping to the common 7 numbers when you enter it into a Task tracking Bug database. eg.

    1 = XS
    2 = S
    4 = M
    8 = L
    16 = XL
    32 = XXL
    64 = XXXL​

    ​Please note: In some teams which only use Small, Medium and Large the following numbering is applyed respectively​ 2, 4 and 8.​​

    Figure: Bad example - Estimation using T-Shirt sizes

    Fibonacci Extended (1-100)

    Planning Poker is a very effective Product Backlog estimation technique and the most common method is using Fibonacci numbers (1,2,3,5,8,13, etc.). This was made popular by Mike Cohn.

    Figure: OK example - Estimation using Planning Poker with large numbers

    Fibonacci (1-21)

    Mike Cohn introduced changes to the original 7 cards, by changing the 21 to 20 and adding 40 and 100 to indicate very large user stories called Epics.

    Ken Schwaber (the father of Scrum) says in his Scrum Certification course, that he is not a fan of the extra cards and says he prefers teams keep to the original 7 cards.

    Figure: OK example - Estimation using Planning Poker with only small numbers

    Doubling

    Estimating using doubling numbers makes relative sizing simple. An 8 point PBI should be about twice the size as a 4-point PBI. This method also simplifies PBI swapping where a PBI is replaced with PBIs totaling the same number of points.

    It has one other advantage over the Fibonacci sequence, it is easier for non-techies because the numbers aren't whacky and the name isn't bizarre.

    Estimate
    1
    2
    4
    8
    16
    32
    64​

    Figure: Good example -Doubling simplifies relative sizing

    Thrown

    Another method of estimating is the "Thrown method" as described Martin Fowler. http://martinfowler.com/bliki/ThrownEstimate.html 

    This is particularly useful if you don't have Planning Poker cards.  Instead of Fibonacci numbers, estimates are from 1 to 5.  It's nice and simple, and you only need the fingers on your hand.

    The action is done in the same method as the game 'Rock, Paper, Scissors'. The options the developer can estimate is 1,2,3,4,5

    Figure: User Story estimates using the "Thrown method"

    Other Tips

    #1 Don't Shout Out
    It will just influence other people's votes.

    #2 Guidelines for Estimating User Stories (aka Anchoring)
    Every team is different, but you can use the following guidelines for sizing User Stories.

    Estimate Value Example User Story
    1A change to a message box
    2-
    3A timeboxed task for 1 day x 1 guy
    5A timeboxed task of 1 day x 2 guys
    8-
    13-
    21More than a month with a couple of guys.
    Tip: Don't include these in a sprint because they are too risky - ask for them to be broken down.
    Figure: Good example - Example User Story estimates

    #3 Using a Chat Program
    If you are working on a project with a remote team, use Skype chat to size stories using Planning Poker.  Everyone should give their points for stories at the same time to avoid influencing each other.

    #4 Big Stories Smell
    PBIs of greater than 1 day are a smell and PBIs greater than 2 days are a stench. If User Stories are estimated at more than 1 or 2 days of work, consider splitting them into smaller pieces to keep them under 1 or 2 days.  See Do You Break Large Tasks into Smaller Tasks?

    #5 Use Spikes
    If you do find a very large User Story, consider using a Spike (aka. an investigation task) to help work out how much work will be involved.

    #6 Small stories

    As some stories can be obviously very small, we allow any member of the Team to propose that a Story is 0.5 points and no further discussion is required.  If there is no objection (i.e. immediate consensus is reached) then the story is given 0.5 points and the Team move on to the next one.  This is the only way a story can have only 0.5 points and always indicates that is was a quick decision and therefore may have some risk attached.

    Related rule

  18. Meeting - Do you update your tasks before the Daily Scrum?

    ​​​​​All team members must update their tasks with status, remaining hours, completed hours and comments prior to the daily Scrum meeting. When the Scrum meeting is in the morning, this should be done at the end of the previous business day.

    Figure: Update the following screen to keep your burn​down rate accurate.

    The reason we did this on TFS 2010 was is because the cube took some time to rebuild the Burndown and it’s very important to have the work status during the meeting. This is not an issue with TFS 2012 as the Burndown will update in real-time, but the rule still applies, as the Daily Scrum flows more smoothly if each developer has already updated the remaining hours on their tasks.

    Related Links
    In Scrum, there are 4 meetings in total that you need to know about:

    Related Videos

    Short Version (3:48)

    Long Version (12:15​)


     

    Note: If you are updating the details of a PBI then follow the rule Do you know when you use @ mentions in a PBI?​​​

  19. Meeting - Do you know what to prepare for each meeting?

    In Scrum, meetings are time boxed. Team members should be well prepared in order to accomplish the meeting goals in time. 

    Daily Scrum Meetings - This is time boxed to 15 mins. All members of the team should be well prepared by:

    What did you do yesterday? e.g. "Yesterday I did xxx"

    What are you doing today? e.g. "Today I will do yyy" 

    Do you foresee​ any impediments or roadblocks? e.g. "I might hit a roadblock today because of xxx"

    • Remember to say "Let's park that conversation for after the Daily Scrum". Major discussions are not to be conducted during the time boxed Scrum meeting.
    • Being online on Skype (especially for team members in different locations). 

    Related Links

    Reports - Do you know which reports are the most important ones to track your progress?

    Management - Do you have daily stand-up meetings (Scrums)?

     

    Review Meetings - all members of the team must be well prepared by:

    • Being available 30 minutes before the meeting
    • Setting up and testing the projector with a computer before the meeting starts
    • Making sure remote members are connected via Skype and/or TeamViewer before the meeting starts
    • Nominating in advance another member of the team to take notes from the presentation
    • Deciding, in advance, the order in which PBIs should be presented; priority, sprint backlog order, logical order and minimizing presenter and presentation medium switching should be taken into account.
    • Controlling the time spent on the PBI presentation
      • Practice the demo beforehand if needed to ensure a succinct delivery. This can be in the form of a pre-prepared video if desired
      • Inform the product owner what the main goal of the PBI is and tell if the team believe it was done or not
      • If the Product Owner previously saw what was done, ideally the member should just mention that and ask if the PBI is accepted
      • If the member needs to show something, show a couple of examples and ask if the Product Owner wants to see something else

    Retrospective meetings - all members of the team must be well prepared by:

    • Having all your tasks from the last sprint closed
    • Having your sprint feedback ready in advance, so members don’t need to think about it during the meeting, saving time
    • Being clear and pointing out issues that need further discussions


    Planning meetings
    - all members of the team must be well prepared by:

    • Having all bugs and PBIs up-to-date on the backlog
    • Having all PBIs on the backlog “groomed” in order of priority (according to the Product Owner)​
    • Understanding all PBIs and the Product Owner’s priorities
    • Being responsible on estimates
    • Volunteering to work on PBIs and tasks, even if they are not related to your best skills – read Do you encourage multi-skilled teams?  
  20. Tasks - Did you know that all tasks are assigned into a User Story?

    In Scrum you work only on tasks in a sprint. These are the reasons that tasks must belong to a committed User Story:

    Creating a new task in TFS, linked to a User Story gives you:

    • Reports over User Stories
    • No tasks done outside of a sprint

     

    The only exception to this rule is when two stories need the same task:
     
    e.g. Package The Product

    In this case, one task can be created but more than one Story can be dependant on it.

    How to do this:

    1. Using Excel query: “Iteration Backlog” add the task under the regarding “User Story”
    2. Using Visual Studio on the "User Story" work item click “Add Related Work Item” and then “Task”
    3. Using Visual Studio on the work items, create a new task and link it back to the “User Story”
  21. Tasks - Do you know that every user story should have an owner?

    During a sprint it can be useful for:
    • The Product Owner to know who to speak to regarding a User Story.
    • The Team to know who will be presenting the User Story at the Sprint Review
    In order to achieve this, one of the Team can choose to be the primary contact for the user story.

    Beware, this is intended for convenience and should not conflict with the following Scrum principals from page 6 of the Scrum Guide
    • The Development team is self-organising.
    • Accountability belongs to the development team as a whole 

     

    image
    Figure: Bad example, the product owner is not sure who to speak to.

    image 
    Figure: Good example, the product owner can now see who he should speak to and developers know where to send done emails.

    TFS_Screenshot4.png
    Figure: we use the 'Assigned To' column to identify who will be presenting the task.

  22. Tasks - When you check in code and associate it to a task?

    In Scrum, you work only on tasks in a sprint, and the task must belong to a committed User Story. As such, when you check in code in TFS, you should associated it with the task you are working on rather than the committed User Story.
    The reason behind this is that doing so provides a better way to track change sets in a sprint and give full traceability for work done during the sprint.
    Change set 123 was associated to User Story 'As an end user I want to be able to lookup customers'Bad Example - The change set was associated to a User Story not a Task
    Change Set 123 was associated to Task 'Create database fields for customer' which is part of User Story 'As an end user I want to be able to lookup customers'Good Example - The change set was associated to a Task
  23. Tasks - Do you know to ensure that relevant emails are attached to tasks?

    ​Often you will receive rich information from your Product Owner (Customer) about tasks. That information can be in the form of Word documents, HTML Emails and Pictures, but you generally receive them in the context of an Email. This should be done by one person called the scribe.​

    The Scribe will:

    1. take screenshots and notes
    2. turn them into multiple emails
    3. add them into the backlog with Team Companion (can be added directly into TFS on Web Browser)

    You need to keep these so your Team can refer to it later, and so you can send a “done” when the task has been completed. This preserves the “history” of the task and allows you to keep relevant partied included in any future conversation.

    Keep the original email so that you can reply DONE and delete the email.

    But keeping it in your email does not help other members of the team if they complete the task and need to send the “done”.

    Worse yet, the description field in Team Foundation Server 2010 (TFS 2010) does not support HTML and images, nor does the default task template support an “interested parties” or CC field. You can attach this content manually, but it can be time consuming.

    More information:

    You should follow the existing Rules to Better Project Management  and attach the email to your task so you can refer to and reply to it later when you close the task:

    When replying to an email with “done” you should follow:

    Following these simple rules will help your Product Owner understand you better, and allow your team to more effectively collaborate with each other.

    An added bonus is that as we are keeping the email history in sync with TFS. When you “reply all” to the email all of the interested parties to the Task are also included. This notifies those that may have been blocked by your task to keep up to date with its status.

  24. Tasks - Do you know to use clear task descriptions?

    When you create tasks in Scrum you are doing this within a time box and you tend to add only the information you need to remember what the task is. And the entire Team was at the meeting and were involved in the discussions around the task, so why do you need more?

    Once you have accepted a task you should then add as much information as possible so that anyone can pick up that task; what if your numbers come up? Will you be into work the next day?

    lottery
    Figure: What if your numbers come up in the lottery?

    What if the Team runs a syndicate and all your numbers come up? The point is that anything can happen and you need to protect the integrity of the project, the company,​ and the Customer.

    Add as much information to the task as you think is necessary for anyone to work on the task.

    If you need to add rich text and images you can do this by attaching an email to the task.

    image
    Figure: Bad example, there is not enough information for a non team member to complete this task
    image
    Figure: Julie provided a lot more information and another team should be able to pick this up

    Note: If you are updating the details of a PBI then follow the rule “Do you know when you use @ mentions in a PBI?​

  25. Reports - Do you understand the implied contract (promises) between Members of the Scrum Team?

    Member of the Scrum Team should understand their responsibilities and respect the implicit contract (promises) they have made.

    Role

    Promises

    The Organization

    • the team that there are stakeholders (including subject matter experts) who will help when needed
    • the team that there are stakeholders (including subject matter experts) who will help when needed
    • they will help the ScrumMaster in the removal of impediments to the Scrum team’s progress
    • the team that they will not change priorities or constraints in the middle of a sprint without team’s consent
    • that being on a Scrum team will not hurt the members’ careers
    • not to divert team members to other work on a Scrum Day during a sprint

    Product Owner

    • to supply an initial product backlog
    • to prioritize the product backlog when needed
    • to be responsive to requests for feedback and clarification
    • empowered “voice of the customer” will be provided to answer business domain questions promptly (minutes or hours, not days)
    • to attend every Review, Retrospective
    • not to change priorities or scope during a sprint
    • not to direct team members to do work not agreed and planned at the beginning of the sprint

    ScrumMaster

    • to keep the team healthy by focusing on the removal of impediments, both internal and external
    • to protect the team from external distractions

    The Team

    • that its work will be transparent, that it will make decisions and solve problems as a group, and that no individual team member will be left behind
    • to take prioritization and scope from the product owner on the team driving the team based on stakeholders interests
    • to use the stakeholders’ time wisely, by focusing on questions that are relevant to the work being done now
    • to do quality work the best way they know how within the constraints set forth by the organization
    • to deliver demonstrable product at the end of every sprint for review and validation by the stakeholders
    • to endeavor to become multi-skilled by sharing and pairing and not relying on experts on the team for specific functions

    Team Member

    • to bring issues, problems, impediments and realities encountered to the team
    • to be available and working with the team on every defined Scrum Day of a sprint in which they committed and any required absences will be scheduled before the beginning of the sprint
    • to attend every Scrum, Review, Retrospective & Planning Meeting
    • to refer any external request that will take more than 15 minutes of Scrum Day time to the ScrumMaster
  26. Reports - Do you know that you should have Scrum Team contracts?

    Working together as a team is hard. Especially with the distractions that are around as part of daily office life. You need all three partied to a Scrum Team, the Product Owner, the ScrumMaster and the Team, to work together to achieve the Sprint Goal.

    Scrum defines three distinct roles that must work together as a Scrum team to produce a successful product. The product owner is responsible for understanding what stakeholders require, interpreting these requirements for the team, and providing clear prioritized direction. The team is composed of those people actively engaged in building the product. The team collectively and members individually are responsible for building the product according to the priorities and requirements provided by the product owner. The team is completely responsible for deciding how to achieve its goals and how to organize its work. Finally, the ScrumMaster is responsible for the health of the process, reporting the progress of the team, and removing impediments to progress.

    From http://www.scrumalliance.org/articles/21-contracts-for-implementing-scrum

    With these roles come a number of promises between the three parties, the Product Owner, the ScrumMaster and the Team. These promises should be formalised so that everyone knows where they stand.

    Contract between the Organization and the Team

    Sample Contract between Members of the Scrum Team

    You will probably need to customise these document, but they are a good start.

  27. Reports - Do you know which reports are the most important ones to track your progress?

    In Scrum there is only one report that the team needs to track their progress.


    Figure: The burndown has all of the information you need to know if you are going to hit your mark

    There are however other reports that matter for management and putting together the bigger picture.

    See Do you get regular updates on costs and progress?

  28. Done - Do you know when to send a done email in Scrum?

    ​​Most devs don't send 'Done' emails. Do you really expect Product Owners to always be checking TFS?

    The better approach is:
        - If task/bug came from a client, when it is completed, send the 'Done' email to Product Owner.
        - If the task/bug is your breakdown of a user story (that the developer did to break down a big user story), then only send the ‘Done’ once the entire user story is complete.
    Note: Send the ‘Done’ email to the Owner of that User Story.

    Don​​​e tips:

    - Include the Task #, Summary and link to the item in TWA.
    - Remember that all your tasks should be under 4 hours
    - Follow the Done Email rules
    - If you completed the task in a different way than previously discussed, mention it.
    - Make sure that every User Story has an Owner as per the rules.

    If you are w​orking on a task:

    When you complete a Task that is part of a User Story you need to send a done email to the Owner of that Story.

    You only need to add the Task #, Summary and link to the item in WIWA. Remember that all your tasks should be under 4 hours, do spending lots of time on a Done Email for a Task would be counter productive. Add more information if required, for example you may have completed the task a different way than previously discussed. 

    Make sure that every User Story has an Owner as per the rules.

    If you are th​e owner of a story:

    When the last task/bug of a user story is complete, you then send a comprehensive done email as per the rules when the story had been completed. Make sure you add a list of all of the Tasks that were completed as part of the story and the Done criteria that you completed.

    Here is the Done Criteria we followed:

        a. Compiled/Built locally    
        b. >30% Code Coverage
        c. All unit tests passed

    Then add an illustration to show this.

    image
    Figure: Good​ example -  This is proof you have met your 'Done criteria'.

    This is all designed to help you Scrum Team members (Product Owner, ScrumMaster and Team) keep a certain quality bar on completion of each chunk of work. Remember that you are not 'DONE' until your team says you are done.

  29. Do you know what a Story Owner is responsible for?

    The role of the Story Owner is like a mini project manager. The Story Owner resolves any road blocks, performs the “Test Please” and makes sure there is a good presentation at the Review Meeting. In addition having a Story Owner makes it easy for Product Owners and others to talk to the right person.

    There are five things that the story owner is responsible for:

    • Manage / Own the story and its sub tasks
    • Make sure a “Test Please” is conducted (or that their story is included in one)
    • Make every effort to show the story to the Product Owner before the Sprint Review (aka a corridor conversation)
    • Prepare for the Sprint Review. Make sure he ready for the review. Have a scribe, have a demo plan/script and get the story accepted quickly.
    • Present the completed Story at the Sprint Review

    Note: Make sure you are ready for the review. Have a scribe and how you are demoing worked out before hand.

    The objective of the Review meeting is to have the story accepted quickly.


    Figure: Out of the box the Microsoft Scrum Template supports a ‘Story Owner’ via the ‘Owned By’ field

  30. Done - Do you know when to do a “Test Please” in Scrum?

    Something you must do it to conduct an internal ”Test Please” prior to releasing anything to a client. This should be conducted by someone outside the Scrum Team and as it is a blocking process must be started within an hour and take no longer than 3 hours to complete.

    Rules to Successful Projects

    1. Do you conduct an internal "test please" prior to releasing a version to a client?
    2. Do you know the 4 steps to do a "Test Please"?

    In Scrum you should conduct a separate “Test Please” for each of the stories. You might be using the same package, but all the bugs and issues found must be rolled up to the Story Owner as they will need to decide on what needs to be done to deliver their Story.

  31. Done - Do you know how to make sure you deliver a build that’s tested every Sprint

     What happens when you leave all the testing to the end of the sprint? You find things that are not done and you have no time before the Sprint Review to fix them.

    Figure: Bad example - if you don’t complete all the tasks the customer will not receive a build in the sprint One way to mitigate this is to aim for a “test please” to occur a few days before the end of the Sprint but you still run the risk of not having enough time to make sure everything is done. 


    Figure: OK example – Send the “test please” before the end of the sprint so you have time to finish everything

    It is preferable to conduct a Smoke Test to make sure that you are comfortable demoing the unit of work you just finished to the customer. One way to do this is to create a Coded UI test for each of the Stories as part of your Definition of Done (DoD) that runs through the functionality you have built.

    In this scenario the “test please” with the customer happens outside of the current Sprint. 


    Figure: Good example – Create a coded UI test for each story to prove that it is complete

    If you are doing Scrum then you should have a User Story fleshed out with a set of Acceptance Criteria. These Acceptance Criteria are agreed with the Product Owner before The Team committed to the story, and define what the Product Owner will accept as complete. This makes it relatively easy to create some automated tests that test for these Acceptance Criteria and help your Sprint Review go as smoothly as possible.

    Any changes found during the Sprint Review get added to the Product Backlog to be prioritised by the Product Owner


    Figure: Ultimate example – Create a Test (could be Coded UI) for each of the Acceptance Criteria agreed with the Product Owner

  32. Do you know how to handle Undone Work?

    The goal is always to complete PBIs for the Sprint Review.

    Often PBIs grow or change and it does not make sense to deliver what was originally proposed in the Acceptance Criteria.

    So think of a way to deliver business value and get it in production, then have a hallway conversation with the Product Owner to see if he agrees with you.

    Assuming approval, then adjust some of the Acceptance Criteria, add "v1" to the PBI name and move some of the functionality to a new PBI with the same title and "v2".​

    Eg.

    • Customer and Contact Form v1
    • Customer and Contact Form v2
    Figure: A PBI has had the scope adjusted and the v1 has been completed. Additional functionality has been moved to v2 and put on the backlog
  33. Ending a sprint - Do you know when to remove stories from the sprint?

    There are two reasons that a story can be removed from the sprint.

    1. Your team notices that they can’t get everything done, and agree with the product owner to remove the story. 
    2. At the Sprint Review meeting the Product Owner rejects the story
    There are a few reasons a team can find themselves in a position where they can't get everything done.
    1. They underestimated one or more stories
    2. Stories were blocked by other stories

    In all cases, when a story is removed from the backlog, it moves back to the top of the backlog and any unfinished tasks left in the sprint are closed.  When the Product Owner next grooms the backlog, or during the next planning meeting, he may decide to prioritise the story high enough to make the next Sprint, but he may not.

     

  34. Ending a sprint - Do you know what to do with partially completed stories?

    You should never have a partially completed story left in your sprint. You need to agree with the Product Owner that the story should be removed prior to the end of the sprint.

    Follow Do you know when to remove stories from the sprint? 

  35. Ending a sprint - Do you know what to do when your sprint fails?

    Having a rejected Sprint is so rare that you should be hard pushed to find any team that has had one.

    If you do then this highlights an underlying communication issue and most likely a lack of participation by the product owner.

    See Do you have a contract between the Product Owner and the Team?

    If however you do get a failed sprint and the Product Owner is not willing to accept the code that has been written then you need to rollback your source code and put all the Stories back onto the backlog.

  36. Do you know what the Sprint turnaround meetings are?

    These are the two meetings at the end of one Sprint and the two meetings at the beginning of the next.  They are usually held in one long meeting.

    The four meetings are:

    1. Review
    2. Retrospective
    3. Planning (WHAT)
    4. Planning (HOW)

    These meetings are normally each timeboxed to an hour for every week of the Sprint.

  37. Do you know what happens at a Sprint Planning Meeting?

    The work to be performed in the Sprint is planned at the Sprint Planning​ meeting. At the Sprint Planning meeting, the following two questions are answered:

    • What can be delivered in the Increment resulting from the upcoming Sprint?
    • How will the work needed to deliver the Increment be achieved?​

    What can​ be delivered in the Increment resulting from the upcoming Sprint?

    The Product Backlog is examined and the Product Owner makes changes so that it is prioritised with Bugs prioritised amongst Stories.

    The Product Owner is then asked to group the top ranking Bugs into Stories for inclusion in the Sprint; see this rule.

    The Team are then advised of their resourcing for the Sprint as there may be additions, subtractions, leave or public holidays which are different to the previous sprint. Considering their previous record and their current resources, The Team decide on the number of story points that they will deliver in the forthcoming Sprint. When The Team are not currently co-located this is often done by voting on an IM group, and discussed until consensus is reached.

    The Team then size (assign Story points to) Stories starting at the top until there are more than enough Stories to fill the Sprint.

    The process of sizing is somewhat formal. Either using cards or IM (essential if not co-located) the team vote privately on the size of the story. They can either use T-shirt sizes of XXS, XS, S, M, L, XL, XXL and XXXL or their equivalent number of story points for which we use the Fibinacci Series of 1/2, 1, 2, 3, 5, 8 or 13, 21 Once the differring votes are in, the ScrumMaster asks the smallest and biggest voters to explain the reasons for their vote. Assumtions and omisions are quickly identified through discussions and the Scrum Master encourages discussion until consensus on the Story points is reached. Any story voted at 13 or higher should be broken down into smaller stories; re-prioritised by the Product Owner and re-sized if necessary.

    Figure: A sample Sprint work item based on the Microsoft Scrum process template for TFS
    Once enough stories are sized, the product Owner is given the opportunity to re-prioritise now knowing the relative sizes. If more stories need then be sized then they are. The ScrumMaster keeps everything going and facilitates negotiation between The Team and The Product Owner until final priority is confirmed and The team commit to a number of stories and the meeting concludes. This meeting should be timeboxed to an hour for every week in the Sprint. However, the ScrumMaster must be sensitive to the meeting producing a workable result.​

    ​How will the work needed to deliver the Increment be achieved?​​

    To answer the second question the team create tasks, with sub-tasks where necessary, for everything that needs to be done to implement the story.  Every task and sub-task should be given an estimate in hours and the same value placed in the Remaining field.

    No actual work on the Sprint should start until this planning is complete.  It is these Remaining hours that determine the first value in the burndown chart which sets the Sprint on its way to completion.  There must be no omissions or The Team will start without an accurate burndown and we all know that "The Team is nothing without a burndown".

    The Team should also ensure that the burndown chart is working and will be automatically sent to all members of The Scrum Team overnight. 

    The meeting concludes when The Team reports to the ScrumMaster that their planning is complete and they are able to display the burndown chart.

    Ideally this meeting is timeboxed to as many hours as there will be weeks in the Sprint.  However, this planning is so essential that it must continue to completion outside the meeting if necessary.

    It is not essential for the Product Owner or the Scrum Master to be present for the whole meeting but they must be available for consultation. The ScrumMaster should formally close the meeting. 

    Once this meeting is finished, the Scrum Master should email the Product Owner with a forecast​.


    In Scrum, there are 4 meetings in total that you need to know about:
  38. Do you know what happens at a Sprint Review Meeting?

    This is the meeting where the Product Owner accepts or rejects the stories in the Sprint and the Sprint itself. 

    The Team, having prepared for the meeting, presents the stories to the Product Owner. 

    One person, often the Scrum Master, presents a summary to the Product Owner of the stories committed at the Sprint Planning meeting and the stories being presented for acceptance.  The Team seeks to have more stories accepted than originally committed.  It is important that the Product Owner knows at the beginning whether The Team believe that they have over or under achieved the Sprint commitment.

    Each story is then presented by the Story Owner for acceptance.  It is the objective of the Story Owner to get the Story accepted as quickly as possible while being totally transparent which includes declaring whether there are any known outstanding bugs in the story (which should already be on the Product Backlog) and adherence to The Team's Done Criteria.

    If a Story is accepted but more work needs to be done, a new Story to cover this work is added to the Product Backlog.  Similarly, if a bug is found during the review, it is added to the Product Backlog.

    If a Story is rejected and returned to the Product Backlog but the Sprint itself is accepted, then a careful decision needs to be made.  If changes have been checked-in to the Sprint's branch then it must be established that these changes have no adverse effect or they must be carefully undone before the branch is merged with the trunk.  For this reason, it is always safer to accept stories with conditions rather than reject them.

    The Scrum Master keeps the meeting on track and to the Timebox by disallowing discussions not relevant to the acceptance or rejection of the story; this is often done by making a note to bring the subject up again in the Retrospective Meeting.

    This meeting is normally time boxed to as many hours as there are weeks in the Sprint.

    In Scrum, there are 4 meetings in total that you need to know about:
  39. Do you know what happens at a Sprint Retrospective Meeting?

    At the end of every Sprint the Development Team performs a Sprint Retrospective also known as the Retro. The Retro provides an opportunity for the Scrum Team to reflect on what has gone well, what has gone poorly, and what the team wants to change. 

    Inspect-and-adapt is a key component of the Scrum framework and the Retro gives Scrum Teams an opportunity to learn from their successes and mistakes.

    The Retro is a time-boxed event that focuses around 3 questions:
    • What went well?
    • What didn't go well?
    • What will we do differently in the next Sprint?
    The Scrum Master facilitates the meeting and collects issues as they are raised. Once every Scrum Team Member has spoken he facilitates debate on each issue so that team consensus is achieved.  The result should produce an actionable outcome, for example:
    • An adjustment is made to the daily processes followed by the Scrum Team
    • An adjustment is made to the Definition of Done
    • An adjustment is made at the organisation level
    • An item is added to the Product Backlog

    To help aid discussion it can be useful for the Scrum Master to prepare items for review by inspecting the Sprint Backlog and statistics such as:

    • Velocity
    • the Burndown
    • Code Coverage

    For example the Scrum Master can find User Stories in the Sprint that were successful / not successful and then facilitate the discussion as to why.

    Figure: The Scrum Master can inspect the Sprint Backlog for items which are Not Done at the end of a Sprint
    Figure: The Scrum Master can inspect the team’s velocity over multiple Sprints
    Figure: The Scrum Master can inspect the team’s Sprint Burndown for insight into how work progressed through the Sprint
    Figure: The Scrum Master can inspect the team’s Code Coverage to for an insight into code quality

    Once all issues have been discussed to the satisfaction of The Scrum Team, the meeting concludes.

    If the timebox limit is reached, the remaining issues should be recorded and dealt with by the Scrum Master.  Any outstanding issues must be raised at the next Retrospective if they are still relevant.

    The time-box for this meeting is usually as many hours as weeks in the Sprint.


    In Scrum, there are 4 meeting​s in total that you need to know about:
  40. Are you flexible with the order you do the work (i.e. Cancelling a sprint)?

    Every now and then your clients are going to want to change their priorities​ and have you work on something which they see as more important than some of the items in your current sprint. Provided that it doesn't have any negative effects overall, there isn't any reason why you can't stick to the "customer is always right" philosophy.

    So what will you do when this happens? ​
    1. Double check that this new item is more important than the current sprint items (if not add it to the product backlog instead​)
    2. Add the new PBI to the current sprint 
    3.  Remove another item of similar size off the sprint and back to the backlog


    In the rare case where the entire sprint goal and all PBIs are no longer high priority, you can instead cancel the entire sprint and start again:

    1. Move any left over work/items to the backlog.
    2. Send a debrief to the client with a note e.g. As per your request we have just cancelled Sprint five and will start on Sprint six. The remaining items have been moved into the backlog.
    3. Send a Sprint Forecast for the new sprint

    This should only be done in extreme circumstances as it is traumatic to the team.

  41. Do you always know what are you working on?

    Team members should always know in what task they are working on and make sure TFS is up-to-date.

    It’s natural that everyone spends some time on grooming, making decisions etc, so it’s not expected that all team members work 8 hours per day on tasks. However, ideally everyone should be doing as many hours as possible.

    If they are doing something for the team that is not a team meeting or for a task assigned to them that will take more than 30 minutes, they should create a new task with an accurate original and remaining estimates. When helping somebody else with a task, the team member should create a new subtask to that task to cover their help.
    To always know the task you are working on is very important for the Burndown accuracy and also make it easy to check what work has been done and what are the impediments.

  42. Do you create a Sprint Forecast? (aka The functionality that will be developed during the Sprint)

    After the Sprint Planning Meeting​ it is useful for the Development Team to send the Product Owner (PO) a Sprint Forecast for the next Sprint. Doing this helps to improve common understanding in, and sometimes to enforce, the relationship between the PO and the Team.​

     
    This is simply an agreement between the Development Team and the PO for one Sprint and should be confirmed via an e-mail at the beginning of every Sprint.

    The implementation team agrees to do its best to deliver an agreed on set of features (scope) to a defined quality standard by the end of the sprint. (Ideally they deliver what they promised, or even a bit more.) The Product Owner agrees not to change his instructions before the end of the Sprint.
    - Agile Project management ( http://members.scrumalliance.org/resources/1119​)

    Each of the Sprints in a Scrum project can be considered a mini-project that has Time (Sprint Length), Scope (Sprint Backlog), Quality (Definition of Done) and Cost (Team Size*Sprint Length). Only the scope can vary and this is measured every sprint.

    ScrumSprintPlanning Figure: Good Example - the product owner should reply to the team and commit to the forecast

    Hi [Product Owner],

    Current Sprint:[Sprint Number]
    Sprint Duration:[Number of weeks]
    Sprint Goal:[Main goal of Sprint]
    Project:[Project N​​​ame]
    Project Portal:
    Product Owner:
    [Link to project Portal]
    [Product Owner Name]
    Sprint Review Meeting:    [Date and Time]


    Attendees: [Names of Attendees]

    As per our Sprint Planning Meeting, and as the Product Owner, you have agreed to the following Product Backlog Items (PBIs) being included in the cu​rrent sprint backlog.

    The Team will do its best to deliver this set of features (Scope), to a defined quality standard (Definition of Done) by the end of the sprint. Ideally the team will deliver what they forecast, or even a bit more, but this can't be guaranteed.

     

    ID

    Title

    Stack Rank

    Assigned To

     

     

     

     

     

    < generate this table as per the instruction on the rule below >

     

     

     

     

     

     

     

    Figure: The sprint backlog

    <This is as per rule: http://rules.ssw.com.au/Management/RulesToBetterScrumUsingTFS/Pages/Do-you-create-a-Sprint-Forecast-email.aspx />

    Figure: Good Example - copy this as email template and send to Product Owner. Subject: <Client Name> Sprint xxx Forecast

    Tip: Use this Outlook email template

    More instructions are as below:

    1. Go to TFS web access page. E.g. http://tfs.northwind.com/tfs/web/UI/Pages/WorkItems/QueryResult.aspx?path=SSW.SharePoint/Team Queries/_Areas/SP2010Migration/Sprint11(current.SolutionUpgrade)/Sprint11 backlog&pguid=32c0d57a-6e46-424f-9411-231bc0f86291
    2. Select Tools | Email All Work Items as a List :
      Update the Table
      Figure: Select Tools -> Email all work items as a list
    3. Ctrl +A and Copy the Email Content:

      Copy the content of the table
      Figure: Copy the content of the table
    4. Paste to the Forecast email, and format the table:
      • Remove some useless columns
      • Make the "User Stories" rows Bold
      • Make the "Task" rows font colour lighter black

      Good Example of a Table
      Figure: Good Example of a Table

  43. Do you create a Sprint Review/Retro email?

    ​​After any Sprint Review and Retrospective, an email should be sent to all the stakeholders to update them on the outcome from the sprint:
    • Subject: <Client Name> Sprint XX Review/Retro
    • This is a reply to the Sprint Forecast email
    • Screenshot of Burndown from TFS
    • Breakdown of work completed (including current code coverage value)
    • Link to test environment
    • Relevant notes from the retrospective

    Hi [Product Owner],

    Sprint in Review: [Sprint Number]
    Sprint Goal: [Goal​]
    Sprint Duration: [Numbe​r of weeks]
    Project: [Project Name]
    Project Portal: [Link to project Portal]
    Test Environment:     [Link to test environment]
    Product Owner: [Product Owner Name]

    Attendees: (Optional as they may be in the to and CC)

     ​

    Sprint Review

     

    ID Title State
    24124UI ImprovementsDone
    24112Integrate Business Logic to MVC appDone
    24097StylingNew
    Figure: Sprint Backlog from [Link to Sprint Backlog in TFS]

     

    As per http://rules.ssw.com.au/Management/RulesToBetterScrumUsingTFS/Pages/RetrospectiveMeeting.aspx, we review:

    1. Sprint Burndown (a quick overview of the sprint)

    Figure: Sprint Burndown

    2. Code Coverage (hopefully tests are increasing each sprint)
    XXX

    3. Velocity (Optional)
    XXX

    4. Burnup (for the release - the whole project, how are we tracking for the big picture?)

    Release Burnup.jpg
    Figure: Release Burnup

    5. Production Deployments (How many times did we deploy to Producti​on?)

    production-deploy.jpg
    Figure: Deployments from Octopus Deploy

    6​​. Application Health Overview Timeline (For the entire spirnt)

    Application Health Overview Timeline.png

    ​Sprint Retrospective

    As part of our commitment to inspect and adapt as a team we conduct a Sprint Retrospective at the end of every Sprint. Here are the results of our Sprint Retrospective:

    What went well?
    <insert what went well from retro>

    What didn’t go so well?
    <insert what did not went well from retro>

    What improvements will be made for the next Sprint?
    <insert what improvements will be made for the next Sprint>

    Definition of Ready - Optional

    <insert the definition of Ready. Normally that the PBIs are Sized with Acceptance criteria added>

    Definition of Done - Optional

    <insert Definition of Done. Normally that it compiles, meets the acceptance criteria, and a test please has been sent if relevant>​

    <This is as per the rule: http://rules.ssw.com.au/Management/RulesToBetterScrumUsingTFS/Pages/Do-you-create-a-Sprint-Review-email.aspx>

    Figure: Good Example - Template for Sprint Review/Retro Email. Subject: Sprint xxx Review/Retro
  44. Do you have a demo script for your Sprint Review Meeting?

    During the Sprint Review Meeting you should demo all features (Sprint goals expressed in User stories) that you have been working on during the Sprint. Make sure to prepare a demo script, which you can follow easily, because you might be nervous.
    The demo script helps if you are going back and want to know what has been done during each Sprint and is nice for documentation purposes as well.
    The demo script should include 3 parts:
    1. Committed user stories 
    2. Steps to show what has been done aka Demo script itself
    3. Give an overview of upcoming user stories, so that everyone has an idea before you go into the Sprint Planning Meeting
    Figure: Store the demo scripts on TFS
  45. Do you know how you deal with impediments in Scrum?

    Exercise – Click Click Scrum

    This exercise uses the VS2010 planning poker deck of cards & TFS

    ​​

    Separate out the cards

    Separate out these as Chance Cards

    Chance Cards Figure: Chance cards

    Separate out these as Point Cards

    Point Cards Figure: Point cards

    Set Timeboxes

    Sprint Planning (What): 20 minutes
    Sprint Planning (How): 20 minutes
    Each Day: 10 minutes ( x 9 days = 90 minutes)
    Review: 20 minutes
    Retro: 20 minutes

    Total for 1 complete Sprint: 170 minutes (~3 hours)

    Sprint Planning Meeting (What)

    1. The trainer acts as PO and gives User Stories & prioritises them
    2. Students clarify the requirements of the User Stories (Details, Acceptance Criteria)
    3. Students do Planning Poker to Estimate

    The Sprint Planning Meeting (How)

    1. Students break User Stories into tasks
    2. Students put estimates on each task (typical times for work in a day e.g 4 hours, 8 hours)

    Each Day in the sprint

    1. Get the students “Click-Click” their fingers instead of doing actual coding
    2. The trainer deals one or two cards from the Chance Cards
    3. The trainer looks up the meaning of the cards (see table below) and the trainer makes up a suitable story that fits the card and the work the students are doing
    4. The students add or change work items based on the scenario of the Chance cards
    5. The team reduces the remaining hours on their assigned tasks, with the assumption that each student works 8 hours
    6. Do the Daily Scrum (describing their day based on the work they just updated in TFS)

    NOTE: It is OK to really code rather than use “Click-Click” development as long as TFS is updated.

    The Review Meeting

    The PO reviews the work of the team (Note: if all the work was “Click-Click” then review the TFS work items to check that they are entered OK).

    The Retro

    Students and PO do a standard Scrum retro for the exercise.

    Meaning of the Chance Cards

    Impediment

     

    • Draw a point card
    • Add the value to the remaining hours of a task
    • Record the impediment

    e.g.  DBA will not give access to the database.
        

    ?

    Clarification

     

    • Draw a point card
    • Add a new task
    • Set the remaining hours of a task to the value

    e.g.  The error message should change from “User Error” to “The process could not be completed, please check the Url value provided for the webservice and try again”.

    0

    Bug

     

    • Draw a point card
    • Create a bug
    • Add a task to the bug
    • Set the remaining hours on the task to the value

    e.g. One of the build scripts fails on the build server, but works on a local dev machine.

    20

    Bubble

     

    • Halve the remaining hours on a task

    e.g. The data access layer supports the validation framework so as that was already implemented the effort expected has decreased.

    40

    Spike

     

    • Draw a point card
    • Create a new User Story
    • Set the User Story points to the value

    e.g. The current implementation may not support real-time display of information with the performance expected by users – investigate

     

    100

    Task blowout

     

    • Double the remaining hours on a task

    e.g. Multiple field data validation was supported in the application but when it was implemented for this work it failed all validations calls and it took ages to find the settings in web.config were wrong.

    Cancelled Sprint

    The PO cancels the sprint

     

    • Cancel all tasks
    • Recycle the User Stories to the Product Backlog

    Team Member
    Leaves

    The Team is missing a Team Member

     

    • Reduce the hours the team works by 8 hours

    Scrum Master
    Leaves

    The Team is missing the Scrum Master

     

    • The team handles the missing SM

    Product Owner
    Leaves

    The Product Owner is missing

     

    • The team handles the missing PO

    Stakeholder Interferes

    Stakeholders are contacting the Team to change priorities and requirements

     

    • The team handles the Stakeholders
  46. Do you know your agility index?

    So you’re agile… or are you? Find out what you’re doing right and what things you can improve on by taking our quiz and finding out your agility index. Do this at each of your sprint retrospectives and ratchet up the quality with each sprint

  47. The Team - Do You Have a Scrum Master Outside the Dev Team?

    Pure Scrum dictates that the Scrum Master could be one of the developers on the team, but we find this is hard for a developer as he will be split between trying to do the work himself, while also ensuring that the Team still uses scrum properly.
    ​We find that a better option is to use a separate Scrum Master so his only responsibility on the project is to ensure scrum is used well and the Product owner is informed of any developments.
  48. Do You Know That Gated Checkins Mask Dysfunction?

    Gated checkins are used to stop developers from checking in bad code and breaking the build.

    This does not contribute to high functioning teams, and instead masks, or even creates dysfunction.

    In the retro the team decides to turn gated checkins on because Jonny and Sue keep breaking the build.

    The build doesn’t get broken any more, because Jonny and Sue now have to fix their code before they check it in.

    This doesn’t mean that Jonny and Sue are writing better code, it just means that they are not checking in code that breaks the build.

    Gated checkins will not improve their skill level, change their attitude or improve the quality of their code.

    The development ninjas on the team are proud of their code, and check in several times per day. Because the gated checkin takes 10 minutes their workflow is impacted.

    They resent Jonny and Sue for having to work this way.

    Gated Checkins mask the dysfunction on the team, and introduce impediments to the high performers.

    Bad Example – Gated Checkins mask dysfunction

    In the retro the team discusses the fact that the build is often broken.
    After a round table discussion about becoming better programmers and building better quality software, the team decides to the following guidelines:

    1. The team will all run build notifications so that everyone knows when, and by whom the build is broken.
    2. If someone needs help with solving a problem, they are going to feel good about asking for help early, and learning something new in the answer.
    3. If someone is asked for help, they will gladly share their knowledge to ensure that the quality of the project is maintained ,and the team help each other to become better developers.
    4. Before checking in, the devs will compile and run all tests. **
    5. If someone checks in and does break the build, they will call out to all members of the team that the build is broken so that no-one gets latest. They will fix the build IMMEDIATELY, and then call out again when it is fixed. (Some teams have a rule that if you break the build three times you have to shout coffee / lunch).
    6. The team agrees that you don’t go home if the build isn’t green. If it comes to the end of the day and you are not sure your code will not break the build – do not checkin. Create a shelveset and resolve the issue properly the next day.
      If you have checked in, the build is broken, and you cannot fix it before going home, you must email all devs on the team, and the product owner with an explanation.
    7. The status of the build is reviewed in every daily scrum.
    Good Example – The whole team should be constantly aware and invested in the status of the build, the quality of the software and in encouraging each other to better developers.

    ** I actually don’t follow this rule when working on small teams of awesome devs, who write code against tests and checkin frequently.

    Instead I encourage the process to be:

    • checkin 4-5 times a day
    • write lots of tests
    • if the tests that you are working against pass- checkin and let the build server do a full compile and run all the tests
    • if you have broken the build, call it out, fix it immediately and then call it out again.

    This is the most productive way for small teams of awesome developers to produce great code… and it's fun !

  49. Do you always work in priority order, unless there’s a good reason not to?

    Although the team will always strive to complete all the items on the sprint backlog within the sprint, it’s not uncommon for them to not finish all of them. If this is the case, you want to at least make sure that the PO's (Product Owner)’s most important items are done.

    Whenever you are choosing your next task, always work from the top down, only skipping items if there is a dependency or another good reason why a lower item needs to be done first.

    Figure: a good example of a team working in priority order. Mid-way through the sprint, the top items have been completed, the middle items are being worked on, and the bottom items have yet to be looked at
  50. Do you estimate “Business Value”?

    ​​​​​​

    ​​​​​​

    ​​OK you say you do Scrum, but do you use the "Business Value" field?

    ​​That's OK, most teams don't... but it is a terrible shame, because developers go to the trouble of estimating 'Effort' and if you have Effort, all you need is Business Value and you can calculate ROI.

    Once you have ROI a Product Owner can use the ROI field to sort priority. Awesome.


    ROI (Return on Investment) is an unbelievably simply calculation.

    Business Value field
    Figure:​ Product Owners should be estimating the Business Value

    ROI = Business Value / Effort​

    ...of course there are other factors to consider.

    E.g. Risk, Dependencies etc and you could make the formula more complicated....

    Priority = (Positive Value - Negative Value) + Risk + Dependencies / Effort

    ...but don't bother.

    The product backlog is just a list of items with rough estimates of both development 'Effort' and 'Business Value'. You will find that ROI will tell you great stuff. It is especially useful for finding the easy high value items to kick off a sprint.

    Product Owners are too busy for this​

    If it is good enough for developers to estimate story points... then it is good enough for the Business to estimate Business Value. Usually devs will use the Fibonacci sequence, but since it is a good idea that the business guys use the same scale, it is best to switch to the doubling method of estimating - Do you know how to size user stories effectively?

    For example, if the "add rich text box" and "add sortable column headings on the grid" have the same business value of 3, the one with the smallest development effort will have higher priority (the ROI is greater).

    In summary, the simple calculated field ROI, can automatically order the backlog tasks for the Product Owner, makes estimating Business Value just good sense.

    Related links

  51. Do you use the My Work hub to manage what you’re working on more easily?

    Visual Studio 2012 contains a great new “My Work” hub in Team Explorer that makes it easy to identify what you’re working on. If you use this feature, when you check in your work you’ll find it’s already linked to the appropriate work item.

    Before starting work on a piece of functionality or a bug, click on the My Work hub and select the appropriate work item from your assigned list before clicking Start.

    Figure: Click on My Work in Team Explorer
    Figure: Choose a Work Item, then click on Start

    When you finish the work and go to check in your changes, you’ll see the work item already selected.

    Figure: The Pending Changes hub shows the work item(s) you’re working on

    The My Work hub also allows you to Suspend and Resume work, making it very easy to switch tasks if something comes up.

    Consider a scenario where you’re working on a new feature and an urgent request to fix a bug comes in. By using the Suspend function, you can shelve your changes, roll back to before you started, and work on the bug with a single click!

    To suspend work on a work item, select it in the My Work hub and click Suspend. This will shelve your changes so you can resume later, and will revert your code back to before you started.

    Figure: Clicking suspend will shelve and then and undo your local changes

    To resume your work at a later time, select the work item from the Suspended Work section and click Resume. This will restore your changes from the shelveset. You can also merge the shelveset into the code you’re working on now.

    Figure: Resuming will restore your shelveset and take you back to your work in progress
  52. Do you know what to do with an incomplete PBI?

    During the Sprint Review, when a PBI is declared “not done” by the product owner (PO), it should be reduced to the remaining effort and put into the backlog.

    It is then reprioritized during the Sprint Planning Meeting and potentially added to the next sprint.

    One of the many good reasons to have the PO present in the Daily Scrums, is that you can communicate with him if a PBI is unlikely to be finished, and so minimize surprises when it comes to the Review.

    1. If no work has been started on the PBI then move it to the next sprint.
    2. If you can reduce the PBI to be able to deliver an increment of business value then reduce the current PBI to contain the tasks for the deliverable increment. The remaining incomplete tasks can be moved to a new PBI in the next sprint.
    3. If the PBI can not be reduced to a deliverable increment then move the PBI to the next sprint. 


  53. Do you know that every user story should have an owner?

    When you are building complicated software and working with customers it is always nice for them to have some idea on who to speak to about a particular story during a sprint. In order to achieve this one of the Team takes responsibility for “looking after” a story. They will collect all of the “Done” emails and make sure that everyone follows the Done criteria identified by the team as well as answering any Product Owner queries.

    image
    Figure: Bad example, The product owner is not sure who to speak to.
    image
    Figure: Good example, The product owner can now see who he should speak to an developers know where to send done emails.
  54. Do you turn an email into a TFS Work Item before starting work?

    ​If a product owner sends an email to the development team with a request, that email should be turned into a TFS Work Item before any work is started or the work is prioritized on the backlog. If you’re using Team Companion, this is easily done with the New Work Item from Mail button.
    Figure: Team Companion lets you create a new work item straight from an email

    If the email's contents or subject do not need changing, then no response email is required. This would create another unnecessary email in the world.

    However, if the subject is unclear, send a response as per the rules http://rules.ssw.com.au/Communication/RulesToBetterEmail/Pages/WhenToChangeEmailSubject.aspx​ and http://rules.ssw.com.au/Communication/RulesToBetterEmail/Pages/ImportanceOfAGoodSubject.aspx​.

    If the request from the client is too large for one Work Item, then it will need to be turned into multiple Work Items as per the rule​ http://rules.ssw.com.au/Management/RulestoBetterSpecificationReviews/Pages/TaskUnderFourHours.aspx​​. In this case, you will need to let the client know this and include URLs to each Work Item.

    Note: Once you've moved the email into TFS as work item, you should delete the original email from your inbox or move it to an Outlook folder called "Moved to TFS" to avoid duplication.​

    2014-11-10_13-17-43-compressor.png
    Figure: Now the new Product Backlog Item is in the Product Backlog

  55. Do you estimate all tasks at the start of the sprint?

    In Scrum, it's important to flesh out the details of a PBI when it makes sense to do so.

    You should estimate your PBIs as soon as you can, but you don't need to break all of your PBIs down into fully-estimated tasks as soon as they're added to the backlog.

    However, before starting work on a sprint you should always break the PBIs in that sprint into estimated tasks.

    Team Foundation Server uses the remaining hours assigned to Tasks to calculate the burndown.  ​By breaking the PBIs down into tasks with estimates, your burndown will start looking correct right from the first day of the sprint.

    burndown_bad_example.png

    Figure: Bad Example - The tasks weren't estimated at the start of the sprint

    burndown_good_example.png

    Figure: Good Example - The tasks were estimated from day one


  56. Do you have a "Definition of Ready"?

    ​As part of the update to the Scrum Guide for 2013, there is a concept of a product backlog being "Ready".​​

    Just like how the team has a Definition of Done as a checklist for completing a PBI, the product owner needs a Definition of Ready to get the PBI in a state that’s ready for it to be added to a sprint. This should be done as part of the refinement (aka grooming) process and will greatly streamline the sprint planning meeting.​

    A recommended “Definition of Ready” would be:

    • Has enough detail for the team to action ​(usually via good Acceptance Criteria)
    • Has Business Value assigned
    • Has effort assigned
    • Is in the Approved state

    Related Rule​:

  57. Do you send "Sprint Forecast" and "Sprint Review/Retro" emails to the client?

    Each sprint has a "Sprint Forecast" email that details what will be worked on during this sprint.

    At the end of the sprint, this should be replied to with a "Sprint Review" email that shows a breakdown of what was completed.

    Each sprint has the following stages:

    1. Planning meeting:
    2. The work is done:
    3. Review and Retro meetings
  58. Do you know the 3 steps to a PBI?

    ​​​The lifecycle of a PBI can be broken down into 3 steps:

    1. Ready

    1. Take the next PBI that was created by the Product Owner
    2. Is the PBI ready?
      Check your PBI against your Definition of Ready. “Ready” PBIs must have Acceptance Criteria. A good Definition of Ready also encourages a test first mentality in requirements e.g. Use Spec Flow (Given, When, Then) and/or create Test Cases and Test Steps first.
    3. Break down your PBI into tasks.
    4. Don't forget to make a task for testing! (So that it is visible in the task board). Note: You can also customize the kanban board​ by adding a new column for testing, but we recommend adding a testing task to the PBI instead.
    KB-customize-board-columns.png
    ​​​Figure: Adding a new "Test" state. This is only visible in the product backlog and not the sprint backlog
    Testing task.png
    F​igure: Testing Task added to PBI. This is the board the team will use for 90% of the sprint, so testing should be clearly visible here.​

    2. Code

    1. Create a branch for your PBI
    2. On the Web Task Board, move your Task into “In Progress”
    3. Code, code, commit… Code, code, commit (Red Green Refactor)
    4. As you complete tasks, move them to “Done”
    5. Repeat 2-4
    6. If you want feedback early, record a video. E.g. Snagit

    3. Done

    Is the PBI “Done”? Check your Definition of Done, and then the Tester:

    1. Open a pull request
    2. Do an "over the shoulder" check of the code
    3. Use Microsoft's "Exploratory Tester" Chrome extension  to test the app 
    4. Make changes based on feedback (and then get more feedback)
    5. Merge changes to master, this automatically deploys (to either Test, Staging or Prod based on process maturity)
    6. Send a "done" email
    Congrats. Your PBI is now ready to be demonstrated during your Sprint Review! (Note: This is also the same process you follow for a Bug work item)
    3StepsToAPBI.jpg
    Good Figure: This image includes all the important steps in a PBI lifecycle. Print this "SSW 3 Steps to a PBI pdf" and put it on your 'War Room' wall.
  59. During a sprint - Do you know when to create bugs?

    This is a very common question asked of teams using Scrum. The answer can depend on a lot of things, such as:

    • How big is the bug?
    • Can it be fixed right now?
    • How important is quality to the product?
    • Are there dedicated testers as part of the team?

    Regardless of your answers, there are basically two types of bugs: those found in code currently being developed (in-Sprint) and those found in code previously thought done (out-of-Sprint).

    In-Sprint bugs

    For stories that are currently in progress, here are some guidelines:

    Typically you want to fix all bugs discovered during the sprint or else they could impact the team’s ability to achieve its Sprint goal:

    • If it’s a small bug (< 1 hour to fix) and won’t impact the burndown, then just fix it
    • If it’s a larger bug (> 1 hour to fix) and won’t impact the ability to achieve the Sprint goal, then create a Bug work item, associate a Task and have a team member perform the fix during the Sprint
    • If it’s a larger bug (> 1 hour to fix) and will impact the ability to achieve the Sprint goal, then create a Bug work item to be prioritized (by the Product Owner) and to be fixed in a later Sprint; you may not be able to achieve your Sprint goal
    • If another team member finds the bug, then they should create a Bug work item and then the team decides if it can be fixed in the current Sprint or needs to be prioritized (by the Product Owner) to be fixed in a later Sprint, in which case you may not be able to achieve your Sprint goal The team decides how many hours “n” equals

    Out-of-Sprint bugs

    For stories that the team had previously considered done, here are some guidelines:

    • If the bug is not critical (i.e. a hotfix), then create a Bug work item to be prioritized and fixed in a later Sprint
    • For a critical hotfix, do whatever needs to be done to get the fix into production, knowing that your current Sprint commitments may be impacted Adjust the team’s capacity accordingly, especially if lots of hotfixes start occurring.
      General tip: don’t create an associated task to fix a bug until the Sprint in which the team commits to fix it

    See rule on​ Do you know how to handle Bugs on the Product Backlog? for how to work with bugs on your backlog.

    Extracted from Accentient’s Scrum Training by Richard Hundhausen.

  60. Bugs - Do you know how to handle Bugs on the Product Backlog?

    Bugs that are introduced and found because of the current work in the Sprint are included in the Sprint and estimated immediately so the burndown remains accurate. All other bugs found independent of the work on the current sprint are placed on the Product Backlog.​

    See Do you know when to create bugs? for detailed information on identifying when something is a bug, and when to just fix it.

    Using the Agile p​​​rocess template

    In the Agile template, you can't assign Story Points to bugs, meaning that they will negatively impact on sprint velocity.

    Bugs found that are independent of the work on the current Sprint are placed on the Product Backlog as a work item “Bug”. The product Owner then ranks the Bugs with priority amongst the User Stories. Bugs cannot have Story Points allocated to them so User Stories need to be created with Bugs as Child Work Items. This is only done when the PO has prioritized the Bug and the Bug is likely to make the next Sprint. At the Planning Meeting, the PO elects which Bugs are to be included and new User Stories are created to group them appropriately with due regard to Severity and Stack Rank. Once the User Stories have been created, The Team estimates the Story Points for each one; the Product confirms User Stack Rank and the Sprint Backlog is planned as normal.

    This process:

    • Works around the problem of Bugs not having Story Points
    • Allows Bugs of the same rank to be sensibly grouped together
    • Prevents arbitrary groupings of Bugs which cannot be properly ranked
    • Follows the estimate just-in-time philosophy of Scrum
    • Prevents small Bugs taking up a whole Story Point

    Using the Scrum​​ process template

    In the Visual Studio Scrum template, bugs are just another PBI and you can assign a business priority and an effort estimate in Story Points. Bugs that make the cut for the next sprint can be broken down into tasks and estimated as required.

    As bugs from previous sprints are just PBI’s, the PO agrees to a list of bugs that will be fixed in the current Sprint.

    The team just fixes any new bugs they introduced in the current sprint.

    If the team finds bugs due to functionality accepted in a previous sprint they log it as a PBI and will complete the fix in a future sprint, unless it is a critical bug, in which case they raise it as an impediment to the current sprint to the PO.

    Examples:

    • Small bug – Text on a label is spelled incorrectly
    • Big bug - There is an error thrown when transitioning from page 1 to page 2 when you hold down the Ctrl key

    ​​2016-02-08_12-02-29.png


    ​​​​​​​​Figure: Bugs can be added "out of sprint" directly into the product backlog in TFS
  61. Done - Do you go beyond 'Done' and follow a 'Definition of Done'?

    ​Having a clear Definition of Done for your team is critical to your success and quality management in Scrum.

    Every team is different, but all need to agree on which items are in their "Definition of Done".

    There are 3 levels of "Done" in communication

    Level 1

    Level 2

    • Sending a "Done" email
    • Screenshots
    • Code

    Level 3​

    • Sending a "Done" email
    • Recording a quick and dirty ​"Done Video"
    • Code (showing a full scenario e.g. a user story)​

    Example of a level 3 "done"

    Subject: RE: Manad - Coded UI Tests #2

    > Create a new CodedUI test on your feedback form – search only to test the Telerik

    Done

    Coded UI Test passes in Visual Studio Figure – Coded UI Test passes in Visual Studio

    Jing Video of the test running: http://screencast.com/t/ps17fqsV

    Figure: Good example - The "done" shows a full scenario

    There are 8 levels of "Done" in software quality

    Start with these examples showing typical "Definitions of Done" from beginner teams to more mature teams:

    Team - Level 1

    • The code compiles
    • All tasks are updated and closed
    • No high priority defects/bugs are on that user story

    Team - Level 2

    • All of the above, plus
    • All unit tests passed
    • Greater than 1% code coverage (not earth shattering, but you need to start somewhere)

    Team - Level 3

    • All of the above, plus
    • Successful build on the Build Server
    • Check in Policy - Changeset Comments Policy (all checkins must have a comment)
    • Check in Policy - Work Items (all checkins must be associated with a work item)
    • Code reviewed by one other team member (e.g. Checked by Bill)
    • Sending a Done email with screenshots
    Check in policy Figure: Good example - Add check in policies to enforce your Definition of Done

    Team - Level 4

    • All of the above, plus
    • All acceptance criteria have been met
    • All acceptance criteria have an associated test passing (aka. Automated functional testing with Web Tests (Selenium), Coded UI Tests, or Telerik Tests)
    • Sending a Done email (with video recording using Jing)
    Acceptance Tests in MTM Figure: Good example - Acceptance Tests in MTM

    ​​​​

     


    Figure: Good example - Done video showing the features worked on

    Team - Level 5

    • All of the above, plus
    • Deployed to UAT (ideally using Continuous Deployment)
    • Complex code is documented (removing technical debt)
    • Product Owner acceptance

    Team - Level 6

    • All of the above, plus
    • Multiple environments automatically tested using Lab Management
    Lab management Figure: Good example - A tester Lab Management to create VMs for testing the application, then defines a test plan for that application with Test Case Management

    Team - Level 7

    • All of the above, plus
    • Automated Load Testing
    • Continuous Deployment
    Acceptance Tests in MTM Figure: Good example - Load testing involves multiple test agents running Web Performance Tests and pounding the application (simulating the behaviour of many simultaneous users)Team - Level 8 (Gold)
    • All of the above, plus
    • Deployed to Production
      Congratulations! You are frequently deploying to production. This is called “Continuous Delivery” and allows you to gather quick feedback from your end users.
       
      You might have everything deployed to production, but it might not yet be visible to the end user. This can be achieved by having “Feature toggles ” in place. The actual release of the functionality is a decision that the Product Owner and business takes.

    More Information:​

  62. Methodology - Do you do Daily Scrums (aka stand-up meetings) ?

    Tight project teams have a Daily 'Scrum' every day at the same time.

    It was once called a 'stand-up meeting' but that discriminates people in wheelchairs.

    It is best to have it standing up, so it's short and to the point. No-one wants to stand around waffling.

    ​​​​​​​​

    Everybody knows the 3 essential questions:

    1. What did you do yesterday? (and did you update TFS/other bug tr​acking system)?
    2. What are you going to do today? (and my current task on the physical task board has my picture on it)
    3. Do you have any roadblocks? (aka issues/impediments)

    Asking these questions of every team member means no-one can hide and everyone remains connected. Further, you can notice what was promised and what was performed. This enables the team to discovers issues quickly and keep abreast of the progress.

    The team's successes and failures are shared, and anyone who knows the answer to someone else's problem can help with a solution, *after* the meeting.

    Figure: Watch a Daily Scrum at Microsoft (short)
    Figure: Watch a Daily Scrum at Microsoft (long)

    "Great video guys. Remember, it is ok to change Scrum, actually it is necessary for success. Just adhere to the values of Scrum. "​

    Stephen Forte (Board member ScrumAlliance.com)

    Follow these essential tips to improve your Daily Scrum meetings:

    Tip 1: Have your Scrum Master review the Sprint Progress at the end

    At the end of the Scrum, the Scrum Master should review the current burn down to check on the progress of the team.

    burndowntfspreview.png
    Figure: The burn down chart in tfs.visualstudio.com (TFS 2012)

    Tip 2: Keep a schedule of the Daily Scrum times on a wall (+ have a recurring appointment in Outlook)

    Hi [Team name],

    As per our conversation, the Daily Scrum for [Project Name] will be held at [Location Name] 11:00AM (Sydney Time) every working day.

    It must be held for 15 mins maximum as per standards:

    Methodology - Do you do Daily Scrums (aka stand-up meetings)?

    Regards,
    [Scrum Master]

    <This email was sent as per the rule: http://rules.ssw.com.au/Management/RulesToSuccessfulProjects/Pages/DailyStandUpScrum.aspx​ /> 

    Figure: Schedule a recurring Daily Scrum meeting in Outlook using this template

    Tip 3: Keep to the schedule. Same place, same time (and start even if people are missing)

    Get started on time. Especially in the beginning, people will be late, but the meeting should be held with the remaining people. Don't worry. People learn.

    If the Scrum Master is not a full time member of the team (often they are), they should attend every now and then to check the Scrum process is being followed and the Daily Scrums are being used synchronize the team and not a general meeting.

    Note #1: The Product Owner (often the client) is not required at the stand up meeting. If he wants to turn up, remind him that he has tape stuck over his mouth, so he does not talk. 

    Note #2: If you are not doing an approved sprint and doing ad-hoc work, then best if the Product Owner (aka client) attends (see Ad Hoc work).

    Tip 4: Do you update tasks before the Daily Scrum?

    Daily Scrums are more effective when team members arrive with their tasks already updated.

    See SSW rule Do you update your tasks before the daily stand-up meeting?

    Tip 5: Don't go into detail

    Keep your answers short and concise. Do not stray from the 3 main questions. Remember to use the "Parking Lot" to record topics to discuss after the Daily Scrum.

    Tip 6: No phones + no checking email. No distractions.

    Technology in the Daily Scrum causes people to lose focus on the goal. The goal is for the team to synchronize by sharing what they are doing. Avoid giving people the opportunity to be distracted easily by forbidding email, SMS and mobile phones from the Daily Scrum.

    Tip 7: Use a task board (even better use an electronic one)

    A task board allows people to visualize what the team is talking about.

    tfspreviewtaskboard.png
    Figure: The Task Board from tfs.visualstudio.com (TFS 2012)

    Tip 8: Carry a pen and paper

    Use a pen and paper to jot things down.
    A whiteboard is also great for "Parking Lot" topics that arise, to be discussed after the meeting.

    Tip 9: Don't let your Daily Scrum become a general meeting - use a "Parking Lot".

    A "Parking Lot" is the place for any discussions that stop the Team from answering the 3 main questions. Only interested people stay for the "Parking Lot" to be discuss issues after the Daily Scrum.

    Tip 10: If you have raised impediments, consider contacting the Product Owner

    Get the Product Owner on the phone
    Figure: Often the Product Owner won’t be at the Scrum. However call the Product Owner if you have an Impediment (aka Roadblock). Communication with the Product Owner is essential and if you haven't touched base with him in the few days, then do so. A disconnected or absent Product Owner is a sign of dysfunction.

    Tip 11: What to do when you're working for a PO directly

    If you don't have a team, and you're doing ad hoc work for a PO directly, it's best to contact him for the Daily Scrum every day if possible, and follow up with an email. This will keep the 2 of you synchronized.

    Tip 12: How do you enter scrum meetings into your timesheets?

    Once you have completed your stand up, add “S” to your timesheet as per Rules to Better Timesheets.

    Tip 13: Use Skype or Lync

    Use Skype or Lync to bridge gaps in geography. 

    Focus on the Flow

    "Extend this rule to focus on 'flow of value', not just people. In a continuous flow mindset, the daily standup is less about the people..... it's about flow. The team faces the scrum board and goes ticket by ticket for all the items in the 'work in progress', finding out what is needed to get it to the next stage.. respecting work in progress constraints."

    Joel Semeniuk​

    More information:

    What happens when you run out of tasks?

    The goal is to be productive for 8 hours of the day, so communicate with the rest of the developers and work with them on any other outstanding tasks. If there are no more tasks then take the next task from the top of the Sprint Backlog.

    What happens if there is a major incident?

    It is important that any major incidents are dealt with first. Start with any major incidents that occurred​ in the last 24 hours.

    Figure: Daily Scrums will alert everyone if there is a major problem and get all brains aligned in the right direction. There is no sense in putting a Band-Aid on a patient's scraped knee if there is a big knife in his eye!
    dailyscrumtweet.png
    Figure: If you like this, retweet  https://twitter.com/AdamCogan/status/168175594209681408
  63. Do you add a version number to PBIs that have multiple iterations

    Sometimes your team will work on a PBI, finish it in the sprint, and receive​ feedback about changes or extensions that weren't originally asked for in the Acceptance Criteria

    ​Bad Example: Unlimited new tasks get added to that PBI so it takes multiple sprints to finish

    Good Example: A new PBI is added to the backlog called "<original PBI name> v2". If this then happens again, a v3 is created, and so on

    This has the added bonus of allowing the Product Owner to see, at a glance, how many rounds of feedback he's given to the team on each PBI.

  64. Do you know how DevOps fits in with Scrum?

    DevOps and Scrum compliment each other very well. Scrum is about inspecting and adapting with the help of the Scrum ceremonies (Standup, Review, Planning and Retro). With DevOps it's all about Building, Measuring and Improving with the help of tools and automation.
    2016-06-08_14-33-24.png
    Figure: Traditional Scrum Process
    2016-06-08_14-30-33.png
    Figure: Scrum with DevOps

    With DevOps, we add tools to help us automate slow process like build and deployment then add metrics to give us numbers to help quantify our processes. Then we gather the metrics and figure out what can be done to improve.

    ​​For example with Exception Handling, you may be using a tool like Raygun.io​ or Elmah and have 100s of errors logged in them. So what do you do with these errors? You can:

    1. Add each one to your backlog
    2. Add a task to each sprint to "Get exceptions to 0"​​​

    The problem with the above is that not all exceptions are equal, and most of the time they are not more important than the planned PBIs being worked on. No developers like working a whole sprint just looking at exceptions. What should happen is:

    1. Have the exceptions visible in your development process (i.e. using Slack, adding as something to check before Sprint Planning)
    2. Triage the exceptions, either add them to the backlog if they are urgent and important
    3. Add ignore filters to the exception logging tool to ignore errors you don't care about (e.g. 404s)
    4. Prioritize the exceptions on the backlog

    ​The goal here is to make sure you're not missing important and to reduce the noise. You want these tools to help support your efforts and make your more productive and not just be another time sink.

  65. Do you have a DevOps Checklist?

    DevOps (Developers and IT Operations) is a phrase used to describe the relationship and/or communication between Developers and IT Operations.

    A DevOps checklist is a simple document that allows development teams to note all of the tasks related to monitoring and application life cycle along with their quality metrics and place them into one of three categories:

    1. Always Tasks
      Always Tasks are tasks that should be performed before the start of a new PBI.

    2. Daily Tasks
      Tasks that are performed at the start of each day.
    3. End of Sprint Tasks
      Tasks that are performed at the end of each sprint.

    Basic Action / Task Format

    Actions or Tasks follow a basic format of: Action / Task Name | Where the task can be performed | Quality Metric

    Action-Table.png

    Figure: Good Example of a Basic Action Table format


  66. Do you have a Preflight Checklist?

    Before starting any work, you should ensure developers take a look at your Application Insights data to make sure everything is performing correctly.


    Most developers check only this first item before starting their work:

    1. Check Unit Tests are Green

    unittests.png

    Figure: Tests are green. I'm ready to start work... or am I?


    More advanced teams check their application insights data as well. This includes:​​

    2. Look for any new Unhandled Exceptions​

    ​See Do you know the daily process to improve the health of your web application?

    ​​App-Insights-Failures.png

    Figure: Unhandled Exceptions - Is there anything you don't know about here?


    3. Look for any obvious performance issues (Server then client).

    See Do you know how to find performance problems with Application Insights?

    performance-4.jpg 

    Figure: Performance - The Server Responses tab shows the slowest running pages.

  67. Record a quick and dirty done videoUnpublished

    ​​When you've finished a PBI you should record a video to send to your product owner and anyone else that is interested. They can even double as release notes for your users.

    Here's a quick video describing how to record and edit a quick done video.

     


    Notice how it itself is also in the done video format?

    Here are the key things to remember:

    • Record in one take. It doesn't matter if you stuff up or something goes wrong, treat it like you're having a conversation with them in the room. If it's super bad, just start again.
    • Remove visible bookmark bars, browser tabs, add-in icons and taskbar items to make it easier to view (See Rule: Do you make sure your screen recordings are easy to view?  ).
    • If you are using a browser such as Chrome then you should first zoom to 125% ideally (See Rule: Do you always zoom in when using a projector?​ ) before the recording.
    • Record at 1920x1080 (aka 1080p). This gives the best balance of detail to size, so it's readable on a mobile phone.
    • Don't edit the video, just include your face at the beginning and end, using the fading functionality.
    • It's supposed to be quick and easy to make. If you spend too much time, you will be less likely to want to do it again in future.
    • Be quick and concise, you don't want to waste other peoples' time either!
  68. Do you know when you use @ mentions in a PBI?

    So when the Product Owner verbally requests a change to a PBI how do you update the PBI to reflect the change and also keep track of the conversation?

    You could send yourself a “To Myself" email and update the PBI description accordingly, but only those people included in the email chain are aware of the conversation.

    bad-mention-pbi.jpg
    Figure: Bad Example – don'​t use emails to update tasks

    Instead, what you should do is use the discussions feature in the PBI and mention the user using “@<username>”. 
    The benefits of using comments are:

    • Quick and easy, no need to compose email
    • History is visible to anyone looking at the PBI (with email, if you don’t cc them, they wouldn’t have a clue)
    • Easy to see all important notes/comments in one place instead of digging through email
    good-mention-pbi.jpg
    Figure: Good Example – Using @ mentions in the discussion
    good-mention-pbi-2.jpg
    Figure: Good Example – Email still gets sent to the users who are mentioned in the discussion, so they can still chime in if any details are incorrect