Agile Tips & Ideas
Read, comment, and enjoy these short commentaries...
Ideally, a Product Owner is to be an actual user of the system who guides the team to build the right product at the right time. The Product Owner is the most important role in an Agile organization and rather than being a painful drag, it can be the most stimulating and empowering job you can take on. The Product Owner represents the needs of their business and guides the Scrum team to build only the most needed and most impactful product with frequent opportunities to revise priorities, share with other key stakeholders, and drive satisfaction in both the builders and the recipients. Once a product vision is established and approved, the Product Owner helps to refine the product's priorities into the small steps it takes to realize it so that with every iteration (2 weeks, or less) something truly valuable is built that moves us significantly closer to that vision.
The Product Owner works with the BA on the Product Planning ==> (the Epic Tree) and Backlog to define, rank, and ‘groom’ the User Stories. Nothing should be released to a Sprint until the Product Owner feels that the Story is fully defined (all Acceptance Criteria from a business perspective is complete) and that the rank (the position in the backlog list when sort is turned off) reflects the value to the business stakeholders.
0 Comments
Do you know what a Sprint Retrospective is? Kanban teams should use them, too! At the Retrospective, the entire Scrum (or Kanban) Team meet to discuss 1.) What went well, 2.) What can be improved, and 3.) What we will do differently in the next Sprint (or next month). Scrum teams should have a Retrospective on the last day of every Sprint. Kanban teams should meet monthly, or more often. Focus on positive change. Look for incremental improvements. Never use this session to assign blame.
Record the results of your Retrospective meetings. Record any Issues, Story ideas, or other details. This is a great way to keep track of your findings and document your progress – following your commitment to ‘Continuous Improvement’! It may seem wrong, but the smaller your Tasks, Stories, Sprints, and Releases, the faster the overall project goes over time. It has been proven again and again. Simple rules: Keep your Tasks to 3 hours, Stories to a size that can be completed in just one or two days; keep your Sprints to just one or two weeks; and keep your Releases to only three or four months of Sprinting. No more. You will be more productive, you will find it easier to deliver value, and the business will receive that value sooner.
As you are finishing requirements development (Release Planning), be sure that all your Stories are small enough to be completed in a few days (1, 2, 3, and perhaps 5 might be okay at this stage, but you will likely want to break them down more if the Story is an 8 or larger). Part of true speed is doing the most valuable work first, so be sure all stories are estimated and ranked by the Product Owner, and only accept enough Stories into the Release plan that you can finish in three months. As with all Agile planning phases, the value of the Sprint Planning session cannot be exaggerated. Planning is essential to keep an Agile team a maximum velocity.
At the Sprint Planning meeting, you must accomplish two things: First, understand and commit to the Stories you will be finishing in the next Sprint, and, second, define every Task for these Stories (as a team!). Everyone must attend because you must not commit to work until you are confident that 1.) You understand it fully, and 2.) You can finish it in just one Sprint. Be sure to use the Sprint Planning tabs to run this meeting. Sprint Scheduling has the Velocity Trend report to show your recent Velocity. Pull your Stories from the ‘Backlog’ on this page and drag/drop them into the new Sprint until you have reached your total Velocity target. Then, go to the Detail Planning tab to add your Tasks, using the 'Plan Story' button beside each Story you selected.. How can companies like Facebook and Google do so many releases every day? Why is this even considered a good thing? It may be more intuitive that if you do lots of work in monthly or quarterly chunks, you will efficiently divide that labor into stages and get more work done in that time. But the opposite is also true. If you divide the work into its smallest units, it becomes much easier to code, test, modify, and approve. In fact, due to defect rates and rework, it is faster to deliver many small units than one big one. Plus, Google, etc. have found that if that small change has value to their customer, even the smallest change is worth doing, and worth doing now. It is a matter of defining small units of customer value (however you define your customer). That is what a User Story is intended to portray. A User Story must define a small unit of improvement that has value to your customer. Ask them to rank your User Stories, and you will always deliver the next increment of the Highest value with each Story.
The Power of the Right Tools: In order to support so many releases of small units efficiently, these companies have advanced the tools of Continuous Integration, Continuous Testing and Continuous Deployment (and other tools). Our DevOps and QA infrastructures are dedicated to advancing this ability. So is our Zero Defect program. If you use the right tools and procedures to detect defects early (to 'fail' early) the cost and time to correct and deploy is greatly reduced. Parasoft, Jenkins, Nolio, Tosca, UFT, etc. all can work together to smooth the transition to continuous improvements to your customer. There is no QA "Team" or Dev "Team" in Agile. There is only one Team – whether Sprint or Kanban. 5 to 9 cross-functional ‘do-ers’ who work together to ‘get to done’. There is no ‘us’ or ‘them’, only ‘we’. Each User Story is completed fastest by Dev and QA acting as a single unit. When Sprinting, you select the Story to include and start working on it together – writing test scripts, writing code, discussing the best way to test this unit of work. Testing is done immediately and debugging is done as soon as testing uncovers issues. This is one of the key differences with Agile. We work on a single unit and get it done, fast – as a team – regardless of role. Be sure you know the name, e-mail, phone number, etc. of your QA and Dev partner. Work very closely, always. Build a strong team and you will find the work goes faster and with fewer defects down the line.
Your Sprint Storyboard should avoid calling out a separate QA step. The Sprint Storyboard is there to track Unit development, Unit Testing and Unit Acceptance. There should be no delay between these steps – Dev-Test-Accept. Use ‘Done’ to show that a User Story has been QA approved, and ‘Accepted’ to show that the Product Owner has accepted this unit of work. Even in Kanban where ‘pull’ Storyboards separate the teams by role, the same is true. It should take no more than a day to complete a 1 point Story in Kanban. Use the Storyboard to work as a team and track work that is blocked or not moving toward Done. Keep your daily Stand-up meeting as brief as possible. Abuse of this meeting can quickly lead to low motivation and participation. Keep all extraneous and even critical conversation to the end of the meeting – and release those not involved. Whether you are doing Scrum or Kanban, you should meet daily to ask the three questions to each person on the team (in the same order every day), and speak so everyone can understand you and what you are working on. Scrum teams – do not problem-solve until the meeting is done. Kanban teams – keep problem solving focused so the team understands the issues you are facing, but do not let it drag on. Always start your meeting on time and do not join late! That shows respect for your colleagues.
Always display the Storyboard at your daily Stand-up. It is good to open the meeting with a quick comment on 'falling behind' or 'too many stories in progress', etc. Be sure that everyone sees the board as a team and that you all learn to recognize what they mean and can react as a unit. A team can best be 'Agile' when all essential disciplines are represented and everyone works together. There is no 'boss' on an agile team. The business representative (the Product Owner) is absolutely part of the team and all members of the team should attend every meeting and participate openly. All teams (whether Kanban or Sprint) should meet daily (brief stand-up meeting). You should be aware of what others on your team are doing. Review the 'information radiators' daily and discuss what you will do differently next time when you see an issue.
The most important team rule is No Blaming. We all work together to improve. Success is a team effort, any failure is also the responsibility of the entire team. Always track your work on a Kanban or Sprint Storyboard (or Teamroom). Use the Storyboard during your daily meeting to visualize your progress (especially the Cumulative Flow chart). Hold regular Retrospective meetings and support each other in Continuous Improvement. What it is: Acceptance Criteria (AC) on any User Story is a tool to clarifying the end-users’ needs.
What it is not: As with the rest of the User Story, it is not a precise programming spec or technical/visual design description. In end-user terms, the AC explains the limitations around your solution that will make it ‘acceptable’ to the user. It tells why they want this and how you know if the need is completely met. It should stimulate conversation between the Scrum team and the Product Owner. Always ask for any clarification during Sprint Planning. The written AC never replaces questions and answers directly from the Product Owner. In Agile, we value conversation over documentation. If you, as a team, do not ask for clarity, you may not understand the request fully - so, do not just simply read and rely on the Acceptance Criteria – ASK (as a team, so everyone hears the answer). Kanban is a form of Agile that is especially effective if used when scope and priorities change unpredictably, but you still want a point of control over your work. Ideally - Kanban works best when your work-team is fixed, but the work they do is variable. Kanban means, essentially, 'Visual Card' and everyone on the team should view this Kanban board (at least daily) to ‘pull’ new work and see revised priorities. It is a good fit for BAU/LO (Business as Usual / Lights On) teams that want to have clear priorities, but also must respond to sudden changes in those priorities, such as emergency production defects, or even minor urgent enhancements. The key to Kanban is maximizing 'throughput' and minimizing 'cycle time' (do fewer things and get them Done!). Kanban provides similar control to SCRUM Agile, but rather than Sprint in 2 week increments, the "Sprint" never ends. Retrospective meetings should be held just as often (every 2 weeks is good) and number of days per story and/or number of days per point should be tracked and discussed.
IMPORTANT: Kanban teams still hold Stand-up meetings (scrums) and are still accountable to a Product Owner who prioritizes the backlog of work items. There are a number of ways that development teams can identify defects while still in the Individual Development Environment (IDE). Once a Story has been understood and accepted for development (during Sprint Planning or the like), you should follow certain coding practices that support zero defects, including…
Tools: There are tools available that can be leveraged while still in the IDE (Java and .Net coding, primarily). Use these tools to support Unit Testing (recommedation: write your own unit tests in JUnit, QUnit, or NUnit, etc. and run the tests with these tools). Some tools also allow you to automate your Peer & Tech Lead code reviews and even run your own Static code reviews. Use tools to help identify defects, and always remove them BEFORE promoting your code to the next level of your SDLC. Projects suffer when you do not complete the planning needed to Sprint at full Velocity. Sprinting should not begun until...
For your Storyboard: At the end of your requirements phase (Product/Release Planning), you should have a complete list of all the User Stories you intend to deliver. This is now your new “Release Project” and your Sprint teams will work from here. Great Agile teams use the planning phase to understand as much about their project iteration as possible before committing developer resources at 100%. Mature Agile teams also attack the hardest or riskiest solutions first. Remember to Fail Early. Do not waste your or your customers' time with work that is not wanted. Are you familiar with DevOps? Agile embraces DevOps to support the quality goals that we all commit to during code development and delivery. Working as a team, developers and QA members test together and also leverage DevOps tools to automate testing and prove readiness for code promotion. Look at the graphic below... Are you getting the most from your DevOps practices and tools? DevOps is not "someone else's job". Each developer and tester should consider this as part of their basic responsibilities.
The Cumulative Flow chart is a great way to ‘see’ the progress your team is making – whether Kanban or Sprint. It shows the flow of work over time by Story Status. If your team is using Kanban, look for an even balance of points in-progress each day. The ‘in development’ band, for example, should be the same thickness most days. If your team is Sprinting, look for 1/3rd of your Stories to be “in progress” at any one time (the 'rule of thirds'), and you should also look for the number of points 'accepted' to grow every day. Never wait to get your work accepted.
Use the chart to see bottlenecks and lack of progress and be sure to share it as a team in your Daily Stand-up (Scrum) meetings. There is a common challenge in all Agile development: breaking down your Stories to a 'small enough' size. What is 'small enough'? Our goal is to be able to code and QA any Story in a single day. That should be your 1 point story. What is the risk? With bigger stories you have two very serious risks to your velocity.
1.) You get distracted or need others' help before you can complete the Story, so it never gets to 'Accepted'. 2.) You create more defects the bigger the Story is. This is a simple fact. Larger Stories take much longer to code and deliver. Smaller Stories allow you to focus and ‘get to done’. Breaking Stories down is not a simple thing and practice makes perfect, here. Be sure to follow the INVEST rule (below), whether Kanban or Sprinting. For your Storyboard: A good way to ‘see’ the progress you make and especially the bottlenecks that larger stories create is to use a Cumulative Flow chart. It shows the number of Story Points (or number of Stories) as they move across your Storyboard statuses. You should also use a Workitem Cycle Time report (if available) to clearly show the number of days it takes to complete your Stories by Story size. If you are following best practices, all User Stories must follow INVEST: I – Stories must be Independent and able to be delivered by your team without help from other teams or waiting for other Stories to be completed N – Stories must be written such that the team can Negotiate the final solution design V – The Story must create Value for the business user. Hint: adding records to a database has value = 0 since it does not provide the business with any new functionality E – The Story must be written in such a way that the team can Estimate the size – the Acceptance Criteria must be clear and specific about the business need S – The Story must be SMALL T – The Story must be Testable and something the Product Owner can view and approve The most important of these may be the 'S' - Small. It is a challenge to break down your work into small, independent deliverables, but the effort offers big rewards, and the more you do it the better you become. One activity that occurs repeatedly during Sprinting is called 'Backlog Grooming'. At least once per sprint, the Product Owner, supported by the BA, re-evaluates the priority (rank) of the next two sprints worth of Stories in the Release Backlog and adds clarity and finishing details. New Stories can be added now, too, but be sure to remove some low priority ones if your scope is fixed. Every Story must be 100% complete, and small enough to be designed, built, and tested in just a couple of days. Be sure to keep two Sprints ahead of the development team.
For your Storyboard: The highest ranked stories should be the ones at the top of your Product Backlog. Be for Sprinting, be sure they each have a Story Point Estimate, and that the Product Owner feels that the Story is fully defined (all Acceptance Criteria from a business perspective is documented) and that the rank reflects the value to your business stakeholders. Agile does not mean 'fast'. It means 'flexible' and able to change direction nimbly. Agile is not intended to be faster than other methods, but it absolutely can be, if you follow a few important steps:
· Plan your work before you start – whether planning a Sprint or a Project Release, dig into the details AS A TEAM and understand where you are going before you begin · Do ‘risky’ things first – and uncover the unknowns earlier · Keep your Project Releases and Stories small – this is very important · Keep your Tasks small – and write them all as a team before you begin to work · Get feedback from every Sprint – as a team, show your work to the largest audience every 2 weeks (Kanban, too) – course corrections are much faster when begun early – and make sure your product owner sees every story the moment QA says it is done Follow all these closely and you will see your overall ‘velocity’ improve. Much of the delay in project delivery comes from inadequate planning and from trying to see too far into the future. But, planning cannot compensate for change. Constant feedback and working as a team are both key to a rapid response to change and a ‘faster’ project. Re-work due to defects and changes of requirements and priorities is expensive and slow. Capture defects and changes early and get more done sooner. One of the most important concepts of Agile that can be easily forgotten in the hussle and bustle of the 'real' world is a focus on 'getting to done'. Whether Scrum or Kanban, your teams are working together as a single unit to finish a User Story in as little time as possible. And, let's agree that to 'Finish' a Story, the Product Owner must have agreed that you met the Acceptance Criteria for that unit of work. Only then are you DONE. You can aid this process greatly by, 1.) keeping all your Stories very small - even if you are doing Kanban, and 2.) helping other members of your team with 'their' work whenever possible.
Work on only 2 or 3 Stories at a time, and... Get Them Done! For your Storyboard: Suggestion: Use a 'Done' column in storyboard to represent QA sign-off on the Story or Defect (only QA sign-off). Then, add an 'Accepted' column to indicate Product Owner sign-off (unless your Product Owner is really an active member of the team and can do the approval as part of QA sign-off). Use a Cumulative Flow chart to watch your Stories getting to done - and always keep the number of Stories in progress low. The more Stories you have in progress, the slower you will 'get to done'. Einstein is quoted as saying, ' insanity is doing the same thing over and over again and expecting different results.' It may seem in Agile we are doing just that - the same thing over and over again. But, we are not insane, are we? Every team needs to ask regularly, 'what can we do better?' Continuous improvement comes from small and frequent changes that lead over time to a significantly better result. Whether Kanban or Sprint, you should be meeting every few weeks to decide on a better way 'next time'.
For your Storyboard: As a team, use your 'information radiators' (reports) to watch your progress and learn from our mistakes. Watch the development-in-progress band of your cumulative flow chart - is it the same (maximum) thickness continually, or is it getting thicker and thinner? Is the ‘accepted’ band growing or stagnant? Sprint teams should check their task burndown charts - are you falling behind, regularly? How can you get better in your estimates? Kanban teams should look at your workitem cycle time report (if available). Are you seeing an improvement in your days-per-point? Use these reports to continuously improve and you will see that even small changes make a big difference over time! |
AuthorPaul Berryman is a passionate application development leader who has earned the title of champion of Agile and DevOps methods and tools for enterprise development teams Archives
January 2017
Categories |