Themes – A Theme is a group of EPICS that represents area of focus. For instance “Product going online” or “moving to cloud” or “launch in India”. Typically program managers assign financial value to themes to ensure objectives and strategic direction of an organization is aligned with program. These are typically at very broader level (Program or entire project level)
EPICs – An Epic is a large story that cannot be completed in a single sprint hence it is broken down in group of user stories. Hence it would make more sense to say that EPICs are collection of related user stories. For instance you say that theme is “Going to cloud” and EPIC is “improve password page usability”. The user story could be “The validation messages should be very clear so that I should be able to correct it easily”
User Stories – User stories is a description of a software feature from an end user perspective who desires the new capability. Precisely it is simplified version of user or customer requirements.
Here is the template for user story
As a <type of user>, I want <some goal> so that <some reason>.
A good user story can convey a clear understanding to programmer about requirement. The characteristic of user stories are
Testable, Estimable, Small, Negotiable, Independent and Valuable.
A specific user story can belong to more than one theme, but certainly does not to multiple epics.
A showcase, demo or sprint review represents one and same thing. A sprint review is an informal meeting that typically takes the form of a demo of the completed features or what is accomplished during the sprint to the product owner.
This can be done as and when the work is completed over waiting for last day of the sprint to arrive. This mitigation the risk of incorporating review comments which may result in sprint failure if the demo is done at the last day of the sprint. In case if there are review comments, that should be fixed and once again demo to be conducted for the story which had review comments.
The whole team should participate. Although the team needs to get the buy in from PO to change the story to done-done while the feedback from whole team helps. You can invite other teams, support or customer as needed.
One of the core objectives of the demo is to review progress against the sprint goal and team commitment. It is an opportunity to get everyone on the same page in terms of what was accomplished, what’s still on progress and what tradeoffs were made.
The entire sprint team work together and plan for next sprint goals. The sprint planning meeting is attended by the scrum master, product owner and rest of the Scrum team. The other teams may be invited on a need basis.
The PO ensures product backlog priority is up to date (At least top level items) for the team to pick up items from the product backlog. The stories are picked up and prioritized. The PO usually talks about sprint goal and once that is finalized, the stories are being picked up to for grooming.
For each story, product owner writes down the description of story and acceptance criteria. While grooming it can be further updated by PO and team. The team gets answers for their queries from PO with respect to functional expectations. In addition to that team work together to identify dependencies, constraints and nonfunctional requirements. The team typically elaborate more on functional requirements as well. The stories are broken down into multiple tasks.
All the groomed stories are then estimated by the team. Each story is tagged with story point or hours. The task usually is tagged with planned hours. The scrum master and team look at the velocity and capacity of the team and commit the amount of work which can be delivered in sprint.
At the end of this meeting, the scrum team would have two artifacts ready
- Sprint Goal
- Sprint Backlog
- I always suggest the team go with pre-grooming. Typically planning happens a day before or when we are about to start a sprint. Understanding every story the first time, grooming, tasking and estimating take too much of time. Due to time constraints, it is not very effective and done half-heartedly. Moreover, all the questions can’t be answered upfront. This is one of the main cause of sprint failures in most projects as you are not sure of what you are committing. One of a good idea is to keep looking at upcoming stories and clarify all the doubts with PO or other stakeholders in advance. Spending 30 minutes to an hour by few folks in team 4-5 days in the previous sprint helps to do much better for next sprint. With this, the planning meeting will have just three goals
- Explain everyone expectations from stories and get aligned
- Once #1 and #2 are done for all the stories, commit sprint.
Note: Many times, the business and competition demand last minute priority work to be picked when you start the Sprint. This is fine as long as it’s minimal.
- PO shouldn’t be telling how much of work team should be picking. The team should take a wise decision by looking at previous sprint capacity. The idea is to have sprint success and continuous improvement.
- Always keep little buffer for planning next sprint items, unknowns in existing sprints and tech debts
- A lot of teams prefer to keep 20% time aside to deal with tech debts. This may be a good idea while I always suggest the team to plan for this 20% during sprint planning and grooming only. What you plan is what can be accomplished.
- Don’t be very aggressive as the quality of software in most cases is more important over quantity.
- The team member shouldn’t be picking up multiple stories in advance. Each and every member should pick one story and once done they should move to the next one as per the priority order specified in Sprint. The exception to picking up the items within Sprint should be ok as long as PO is good with that.
- Always create a task for stories. Don’t just include tasks which have business values while do consider tasks related to development and testing. For instance testing, code reviews, writing tests etc. Keep in mind, don’t write too many tasks.
- Try to break down the story to as small as possible while if the estimation is going beyond then it’s important to divide that into smaller stories. There are instances where you can’t break down the story to the level where you are not getting business value out of it which is OK at a times but do avoid this situation as much as possible.
- The story where lots of research is involved and there are unknowns which need to be unearthed, prefer to go with Spike.
- Trust each other and support each other.
- Pair when needed while do not work on the same task in series unless absolutely necessary. I have seen with the offshore-onshore model, the story is being worked on one story at offshore and further, it is handed off to another team member at onshore. These cycles keep repeating. The amount of productivity loss happens in this approach is not worth it.
Important Tip – The scope creep can be managed within Sprint with only two ways
- Refuse new work in the middle of Sprint and take up that in next Sprint.
- If it’s absolutely mandatory to pick the work in the middle, you need to take out an equal amount of work from Sprint.
At times, you are done with Sprint in advance, in that case, you can pick more work while it is always better idea to increase your velocity and focus on tech debts, testing, and quality practices. You can even spend time on learning which is usually way more important than we usually think
No matter how great your team is, there is always scope to improve and get better. The retrospective is way to accomplish this periodically. The main focus is to look at what is working and what is not? Further what are the action items we have based on our learning. The core focus of retrospective is continuous improvement which is one of the core philosophy of agile.
The primary agenda of this meeting where every team member is expected to bring their points are
- What worked well?
- What did not work well?
- Action items to improve the process (Mainly action items are result of what did not work well)
How to do it
- Set the stage. Invite entire team for a meeting (Scrum Master, Product Owner, Team and Customer if possible)
- Give 10 minutes to everyone to enter their points towards 3 agenda items stated above. The recommendation is to use a tool (For instance noteapp) and send this to whole team in advance to enter their points. This would save time for team in meeting and moreover give enough time to team members to think and state their points.
- Start with talking about previous retrospectives action items. Close the items which are accomplished.
- Talk about what worked well, appreciate people and motivate team to continue utilizing the best practices.
- Further Discuss what did not work well and come with action items
- Assign owners for every action item.
- Close the retrospective while action items to go to action item register.
- Typically it should happen after every sprint and should last between 30 to 60 minutes.
- The whole team should participate.
- This can be considered as “lesson learned” meeting. The notes can go to organization process assets (Remember “PAL” or “Process Asset Library”).
- The owners must be assigned to action items. The next retrospective should start with open items of previous retrospective meetings. I have seen, individual teams have excellent ideas while post retrospective nobody really thinks about it.
- One of the recommendation is to have retrospective of retrospectives to make it better.
- Don’t point fingers instead work as team and support each other.
- Do not forget to appreciate your team members.
The agenda of this meeting should be:
1. What did you accomplish since the last meeting
2. What are you planning to work on until next meeting
3. What issues are blocking your progress (Impediments)
- This is not a status to management instead making sure the whole team is on same page. Stand up is not a meeting. It should clearly intended to be standup.
- The stand ups should be strictly time-boxed to 10 minutes. The standard scrum practice says 15 minutes while with my last many years of experience, I see better results with 10 minutes.
- Hold the meeting “Without chairs”. Everyone must stand and speak up.
- Plan to do this in morning. If you have sprint team outside of your country and common meeting held only in the evening then plan to meet whoever is available in morning for 5 minutes for quick sync up with same agenda. The evening stand ups are just status or post mortem which doesn’t serve the purpose of stand ups.
- Everybody in team reports to three agenda items listed above to rest of the team.
- Prefer to have this meeting at the same place and time everyday. Meeting morning is very important as it helps set the context for upcoming work.
- The quick questions and clarifications can be covered at a times while do remember that the meeting must have to be end within 10 minutes. Please understand when I say quick, I am referring closed ended quick questions. The rest everything should go offline or should be addressed with other meetings.
- The meeting should not be cancelled even some of the members are not present. As a team member it is extremely important for you to attend the meeting if you are not on leave that day.
Following are the TOP 10 agile interview questions. There is another list of critical questions while these are expected in most interviews. Moreover these are very basic, and every interviewee is expected to excel in his/her responses for these questions.
- What is agile roadmap looks like? Explain agile process start to end? How do you start agile project? What is the difference between product roadmap and Release planning?
Refer Agile Roadmap
- What is Test Driven Development? How does it differs from traditional method where tests were written before the actual code?
- What is continuous integration? How do you achieve that?
- What is scope creep and how do you manage that within sprint?
- What are the core artifacts of sprint? Elaborate them?
- What is the role of Scrum Master, Product Owner and Team Member? Or what are the typical roles in Scrum?
Refer Scrum Roles and Responsibilities
- What is Velocity and Story Points? How do you relate story points to hours? Is it right?
Refer Story Points Vs Time
- What type of metrics or reports you have in agile? Explain?
- Explain Sprint Ceremonies? Planning & Grooming, Stand-up, Demo or Showcase and Retrospective.
Scrum Ceremonies – Daily Stand Ups
Scrum Ceremonies – Planning and Grooming
Scrum Ceremonies – Retrospectives
Scrum Ceremonies – Demo/Review or Showcase
- Explain Agile in 2 minutes? When should you use Agile? Explain the instances when you prefer to go with Waterfall over Agile
Refer Agile in 2 minutes
I would be writing other important questions in addition to questions focused for Managers, Directors, Agile Coaches, Scrum Masters, Team Members and Product Owners in my upcoming blogs.