Recently while cleaning up my photo albums I found some interesting old pictures which were captured while I was leading a Scrum project. These white board pictures illustrate how we incrementally deliver from scratch. Looking at these pictures I really enjoy recollecting the days when I was working together with my team; days we spent suffering, learning and growing together.

Sprint # 0.

At that time the team was just busy like crazy. We got all infrastructure stuff ready in this period of time (we call it Sprint 0). The team also made some smart decisions; one of those was that we use a white board as our User Story completion tracking system, and use different color sticky notes for different types of User Stories.

Sprint # 1.

This picture was taken in the middle of our first Sprint. We got our Product Backlog prioritized and started from some foundational technical tasks. Fortunately, my team was strong enough so that we also delivered some of the highest priority (which also happened to be some of the simplest) User Stories.

Sprint # 2.

This picture was taken on the last day of our second Sprint. Things were just going smoothly. We delivered all the planned User Stories and had a very successfully Sprint Review meeting to our client. The client was happy and we did the Sprint planning for the next Sprint right after the Sprint Review meeting. The team was excited and confident that we can deliver more story points in the next Sprint.

Sprint # 3.

Maybe the team was too excited in Sprint # 2 to realize life never becomes easy. Looking at the picture we took in the middle of Sprint # 3, I can still feel the pain the team was suffering at that time when we had to admit we could not deliver all the planned work.

Sprint # 4.

Things were becoming even worse. This picture was taken the last day of Sprint # 4. That day the team was really frustrated because we were hit by a significant failure: we failed to deliver most of the planned stories. For two consecutive Sprints that the team had missed our commitments. We spent 2 hours having a serious retrospective meeting to decide how we can adjust and catch up with the plan in the next Sprint.

Sprint # 5.

One action the team took was to communicate with our client honestly about the current problems the team was having. The client re-prioritized our Product Backlog so that we got extra time to clean up our technical debts in our Sprint # 5. Thankfully our client understood the team needed more time to learn and grow, although they might not have been that happy. Anyway the team learned from the failure and got extra time to fix the issues.

Sprint # 6.

The team worked extremely hard in Sprint # 5 and 6. Sprint # 5 was a milestone – we not only cleaned up our technical debt but also delivered several additional User Stories. By the end of that Sprint we were finally feeling that we were taking back control.

Sprint # 7.

I lost the picture of that Sprint.

Sprint # 8.

We were getting closer to the end of the project. As we often experience requirement changes started coming into our backlog. All the high priority User Stories on our Product Backlog have been delivered, now the client was adding changes almost every day. Managing those changes became the biggest headache for the Sprint.

Sprint # 9.

The additions in Spring 8 had been implemented. Only a few low priority stories left on our To-do list. The client was planning to throw them away directly and the team started doing regression testing again and again to make sure we deliver fewer bugs. The biggest lesson we learned in Sprint 9 was that we should have written enough automated functional test scripts so that we don’t need to be working over time until mid-night that Sprint.

Sprint # 10.

This was the last Sprint of this project. We’ve done enough tests, and we were very confident about the quality we delivered. The client was also satisfied. They were ready to do the big final Demo to the sponsor. Several key team members started taking vacation. They needed to compensate their families for those crazy days and nights they were staying in the office.

That is the typical life inside Perficient China office, full of happiness of experiencing new things every day, full of pain of dealing with different challenges and issues all the time, full of excitements of continuously learning and growing. I’m feeling lucky that these happen all the time in my life in this office.

最新文章

  1. 在.NET Core之前,实现.Net跨平台之Mono+CentOS+Jexus初体验
  2. Auty 2017——WebMonitor接口检测平台
  3. ASP.NET Razor——ASP.NET Razor - C#代码语法
  4. 将ECSHOP会员注册页面的Email修改成非必填项
  5. 【转】利用optimize、存储过程和系统表对mysql数据库表进行批量碎片清理释放表空间
  6. Android进度加载的Loading效果
  7. 使用秘钥对登录Linux系统
  8. 解决Fragment中使用ViewPager时,ViewPager里的Fragment错位和空白问题
  9. POJ1006: 中国剩余定理的完美演绎(非原创)
  10. 详解EBS接口开发之应收INVOICE导入
  11. C# 反射 判断类的延伸类型
  12. C 线性表的链式存储实现及插入、删除等操作示例
  13. SQL Server 使用 Merge 关键字进行表数据同步
  14. 【转】Vue中mintui的field实现blur和focus事件
  15. Linux服务器安装配置Nginx服务器
  16. 点评10款Github上最火爆的国产开源项目
  17. 【Scala】Scala-使用ExecutorService-等待所有线程完成
  18. 单元测试中用@Autowired 报null (空指针异常)
  19. react项目打包后路径找不到,项目打开后页面空白的问题
  20. js一些常用方法总结

热门文章

  1. 安徽师大附中%你赛day4T2 演讲解题报告
  2. 【NOIP模拟赛】Drink 二维链表+模拟
  3. Android-使用ViewFlipper实现轮番切换广告栏
  4. CentOS 6通过yum升级Git
  5. mysql修改表中某个字段的默认值
  6. LwIP - raw/callback API、协议栈API(sequential API)、BSD API(或者说 SOCKET API)
  7. CentOS 6.4安装配置ldap
  8. x:Class, x:Key
  9. HibernateException: Unable to instantiate default tuplizer [org.hibernate.tuple.entity.PojoEntityTup
  10. 51Nod-1586-约数和